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Abstract;  The  Construction  Operations  Building  Information  Exchange 
(COBIE)  specification  denotes  how  information  may  be  captured  during 
design  and  construction  and  provided  to  facility  operators.  COBIE 
eliminates  the  current  process  of  transferring  massive  amounts  of  paper 
documents  to  facility  operators  after  construction  has  been  completed. 
COBIE  eliminates  the  need  for  post-hoc  as-built  data  capture  and  helps  to 
reduce  operational  costs.  This  report  describes  the  background  and 
process  used  to  create  and  implement  COBIE.  An  international  panel  of 
experts,  facility  operators,  construction  managers,  and  asset  managers 
participated  in  this  project  under  the  auspices  of  the  Development  Team  of 
the  National  Building  Information  Modeling  Standard  (NBIMS).  This 
report  documents  the  requirements  analysis  that  led  to  a  pilot 
implementation  standard,  specifications  for  the  pilot  implementation 
standard,  and  the  creation  of  an  Information  Delivery  Manual  with 
process  maps  used  to  link  user  requirements  into  the  Industry  Eoundation 
Class  model. 


DISCLAIMER:  The  contents  of  this  report  are  not  to  be  used  for  advertising,  publication,  or  promotional  purposes. 
Citation  of  trade  names  does  not  constitute  an  official  endorsement  or  approval  of  the  use  of  such  commercial  products. 
All  product  names  and  trademarks  cited  are  the  property  of  their  respective  owners.  The  findings  of  this  report  are  not  to 
be  construed  as  an  official  Department  of  the  Army  position  unless  so  designated  by  other  authorized  documents. 
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1  Introduction 

Background 

Building  owners  bear  significant  costs  that  arise  from  the  lack  of  interop¬ 
erability  with  regard  to  electronic  facility  information  [Gallaher  et  al. 
2004].  Some  facility  managers  have  attempted  to  create  facility  informa¬ 
tion  for  use  in  maintenance  management  systems  or  to  document  as-built 
conditions,  but  even  on  large  projects,  such  efforts  are  very  costly.  Al¬ 
though  large  owners  have  been  able  to  develop  facility-specific  or  proprie¬ 
tary  information  exchange  formats,  those  formats  directly  hinder  potential 
bidders  who  do  not  use  the  required  software,  or  else  they  increase  the 
cost  of  work  because  bidders  must  use  multiple  software  systems  in  order 
to  participate.  In  other  words,  the  lack  of  data  interoperability  either  ex¬ 
cludes  otherwise-qualified  bidders  or  pushes  higher  project  information 
processing  costs  from  the  facility  owner  to  the  builder. 

The  current  state-of-practice  is  limited  to  the  exchange  of  “electronic  pa¬ 
per,”  or  e-paper.  The  most  successful  e-paper  method  requires  that 
scanned  copies  of  paper  documents  be  provided  at  project  turnover.  The 
requirements  for  such  documents  are  identified  in  the  Operations  and 
Maintenance  System  Information  (OMSI)  specification,  developed  by  the 
Naval  Facilities  Engineering  Command  (NAVE AC).  OMSI  has  now  been 
incorporated  into  Unified  Eacilities  Guide  Specification  (UEGS)  01781, 
which  is  used  by  the  U.S.  Army,  U.S.  Navy,  and  the  National  Aeronautics 
and  Space  Administration  (NASA)  [UEGS  01-78-23,  July  2006]. 

Part  of  the  solution  to  the  data  interoperability  problem,  currently  being 
considered  throughout  the  international  construction  community,  is  a 
non-proprietary  construction  operations  data  model  created  by  the  Inter¬ 
national  Alliance  for  Interoperability  (lAI).  The  mission  of  the  lAI  is  to 
provide  “a  universal  basis  for  process  improvement  and  information  shar¬ 
ing  in  the  construction  and  facilities  management  industries”  [lAI  2007]. 
The  common  language  for  the  lAI  effort,  called  the  Industry  Eoundation 
Classes  (lECs),  provides  a  shared  framework  for  the  exchange  of  facility 
information. 

While  it  is  feasible  for  large  facility  owners  and  software  firms  to  develop 
proprietary  standards  for  information  exchange,  the  variety  of  such  re- 
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quirements  limits  the  capability  of  small  (or  non-integrated)  construction 
industry  members  to  participate.  One  key  criterion  for  a  successful  data 
exchange  effort  is  that  it  must  be  very  easy  for  contractors  to  use.  A  key  to 
a  product-  or  system-related  information  exchange,  such  as  those  included 
in  OMSI,  is  that  manufacturers  who  currently  provide  paper  documents 
must  be  encouraged  to  provide  digital  data  instead.  Establishing  a  model 
for  manufacturers  to  provide  electronic  product  information  is  the  goal  of 
a  project  under  way  at  the  National  Institute  of  Building  Sciences  (NIBS). 
The  goal  of  the  Product  Guide  portion  of  the  NIBS  Whole  Building  Design 
Guide  rhttp://www.wbdg.org/1  is  to  provide  a  place  for  manufacturers  to 
submit  electronic  information  that  may  be  utilized  during  building  design, 
construction,  and  operation. 

In  December  2005,  a  group  was  formed  in  the  United  States  specifically  to 
promote  the  development  of  a  National  Building  Information  Model  Stan¬ 
dard  (NBIMS).  NBIMS  Development  Team  members  and  interested  stake¬ 
holders  have  contributed  to  the  work  documented  in  this  report:  a  compo¬ 
nent  of  the  NBIMS  standard  called  COBIE,  the  Construetion  Operations 
Building  Information  Exehange.  The  purpose  of  COBIE  is  to  improve  how 
information  is  captured  during  design  and  construction,  and  then  pro¬ 
vided  for  operations,  maintenance,  and  asset  management  purposes. 
COBIE  eliminates  the  need  to  create  and  transfer  boxes  full  of  paper  con¬ 
struction  documents  to  facility  operators  following  completion  of  the  pro¬ 
ject.  COBIE  also  eliminates  the  need  for  post  hoc  as-built  data  capture, 
and  it  will  help  to  reduce  operational  costs. 

Objective 

The  objective  of  this  work  was  to  document  the  background  and  process 
used  to  create  and  implement  the  pilot  version  of  the  COBIE  specification. 
This  report  includes  an  implementation  of  the  pilot  COBIE  specification. 

Approach 

An  international  panel  of  experts,  facility  operators,  construction  manag¬ 
ers,  and  asset  managers  participated  in  this  work  under  the  auspices  of  the 
NBIMS  project.  The  overall  approach  to  this  project  consisted  of  six  steps, 
as  shown  in  Eigure  1-1. 
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Figure  1-1.  COBIE  project  approach. 

The  first  step  was  defining  the  problem  to  be  addressed  by  COBIE.  Part  of 
the  problem  definition  involved  identifying  assumptions  about  the  prob¬ 
lem  domain  and  recognizing  which  issues  are  beyond  the  scope  of  the  pro¬ 
ject. 

The  second  step  was  a  survey  of  literature  documenting  the  state  of  prac¬ 
tice  and  technology  related  to  information  exchange  between  designers, 
builders,  and  operators.  The  survey  encompassed  publications  by  acade¬ 
mia,  government  agencies,  and  not-for-profit  organizations.  Current  con¬ 
tract  language  for  the  exchange  of  information  and  previous  demonstra¬ 
tion  projects  also  was  identified. 

The  third  step  in  the  research  process  was  the  creation  of  the  Information 
Delivery  Manual  (IDM).  IDM  is  an  emerging  international  standard  for 
the  development  and  creation  of  interoperable  building  information  mod¬ 
els  based  on  the  IFCs  [lAI  2006].  The  IDM  has  three  parts  that  define  the 
business  process,  information  exchange  requirements,  and  information 
exchange  format,  respectively.  In  the  IDM  business  process  step,  called  the 
Business  Process  Modeling  Notation  (BPMN)  [Object  Modeling  Group 
2006],  was  used  to  capture  the  steps  relevant  to  COBIE.  Information  ex- 
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changed  at  specific  points  in  the  business  process  will  be  identified  and 
described,  and  the  detailed  format  of  the  information  handoff  required  be¬ 
tween  software  systems  will  be  described  using  the  IFC  model. 

In  the  fourth  step,  verification  took  place  in  a  fully  open,  team-based 
setting,  with  guidance  and  advice  shared  among  project  stakeholders,  the 
NBIMS  Development  Team  peer  review  group,  and  international  IFC 
modeler  peer  review  group.  The  participants  included,  but  were  not 
limited  to: 

•  participants  in  previous  and  ongoing  related  projects 

•  facility  operations  and  maintenance  staff 

•  facility  asset  managers 

•  design  and  construction  community  members 

•  government  agencies. 

In  the  fifth  step,  validation  of  the  effectiveness  of  the  COBIE  specification 
and  COBIE-compliant  software  systems,  a  series  of  real  construction  con¬ 
tracts  will  be  modified  to  include  a  COBIE  specification  section.  An  early 
draft  of  some  of  those  COBIE  specifications  is  included  in  this  report. 

Mode  of  technology  transfer 

COBIE  technology  is  being  transferred  through  multiple  channels  of  activ¬ 
ity,  including  the  following: 

1.  development  of  contract  language  that  federal  agencies  may  use  to  require 
the  submission  of  COBIE  data  by  construction  contractors 

2.  creation  of  instructions  and  sample  data  to  help  construction  contractors 
to  easily  prepare  the  required  COBIE  data 

3.  coordination  with  national  and  international  standards  bodies  to  ensure 
that  COBIE  requirements  meet  international  interoperability  standards 

4.  coordination  with  professional  and  trade  associations  to  ensure  that 
COBIE  requirements  meet  relevant  business  needs 

5.  updating  the  COBIE  format  as  requirements,  business  processes,  and  in¬ 
teroperable  technologies  change  over  time. 

6.  posting  templates,  guides,  and  related  technical  content  on  the  National 
Institute  of  Building  Sciences  (NIBS)  Whole  Building  Design  Guide 
(WBDG)  web  site  rhttp://www.wbdg.org1  to  facilitate  the  widest  and  most 
cost-effective  dissemination  of  COBIE  standards. 
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1  Problem  Definition 

The  current  handover  of  information  between  construction  and  operations 
yields,  at  worst,  boxes  of  papers  filled  with  the  technical  descriptions  of 
materials,  products,  equipment,  and  systems  that  are  stored  and  never 
used.  In  the  best  situation,  documents  are  provided  electronically  on  CD 
created  following  construction  and  filed  on  a  local  area  network.  While  a 
significant  amount  of  effort  is  spent  to  ensure  the  startup  tuning  of  equip¬ 
ment  and  systems  is  correct  during  commissioning,  there  is  no  equivalent 
process  for  “data  commissioning.” 

Today  there  is  no  way  to  provide  facility  operators  with  non-proprietary, 
interoperable  versions  of  the  data  they  need  to  effectively  operate  modern 
facilities.  Without  such  information  operators  must  enforce  proprietary 
information  systems  or  re-key  information  into  Computerized  Mainte¬ 
nance  Management  Systems  (CMMS). 

One  recurring  theme  in  discussions  about  interoperable  data  standards  is 
a  kind  of  “chicken  and  the  egg”  argument.  Software  vendors  state  that  they 
can  provide  whatever  software  is  needed  for  owners.  Owners  claim  that 
software  vendors  are  not  providing  what  owners  need.  The  reason  such 
arguments  continue  is  that  owners  have  not  been  willing  to  identify  their 
requirements  in  a  generic  way. 

The  problem  to  be  addressed  by  COBIE  is  that  of  the  lack  of  definition  of 
open-source,  interoperable  requirements  for  the  exchange  of  information 
between  the  construction  and  operations  phase. 

Many  differences  in  points  of  view  between  contractors,  operators,  main¬ 
tainors,  and  asset  managers  exist.  One  of  the  differences  in  points  of  view 
occurs  when  thinking  about  information  standards  themselves.  Many  view 
information  standards  as  bits  and  bytes  of  individual  data  exchange  ele¬ 
ments.  Efforts  over  the  past  decades,  not  resulting  in  a  useable  informa¬ 
tion  exchange  format,  have  demonstrated  that  this  approach  is  incorrect. 
The  COBIE  project  will  attempt  to  bridge  these  gaps  in  perception  by  iden¬ 
tifying  the  commonality  in  the  processes  that  of  the  groups  use  to  accom¬ 
plish  their  daily  activities.  Given  the  commonality  in  process,  commonality 
in  data  sources  and  uses  will  be  mapped  by  COBIE. 
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Given  that  the  requirements  for  data  can  be  agreed  upon  by  all  project 
stakeholders,  the  final  step  will  be  the  creation  of  the  data  exchange  for¬ 
mat  itself.  This  format  will  need  to  capture  information  as  it  is  created, 
rather  than  rely  on  post-construction  surveys  or  audits  as  is  current  prac¬ 
tice.  The  format  will  also  need  to  be  based  on  an  open-source  platform,  the 
IFCs.  Direct  use  of  IFCs  alone  is  not  possible,  however.  Agreements  among 
stakeholder  representatives  must  be  created  to  define  what  exact  informa¬ 
tion  is  to  be  provided  by  whom,  to  whom,  and  when. 
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2  Survey  of  Practice  and  Technology 

This  chapter  surveys  the  literature  of  professional  practice  and  that  of  aca¬ 
demia  to  identify  those  current  and  past  efforts  that  inform  the  current 
project.  Initially,  current  information  exchange  practices  in  the  private 
sector  are  discussed.  Next,  the  efforts  of  industry  associations  to  create  in¬ 
formation  exchange  standards  for  the  construction  industry,  related  to 
COBIE,  are  discussed.  Third,  the  business  processes  used  by  for  owners 
and  builders  related  to  materials,  products,  equipment,  and  systems  in  the 
U.S.  public  sector  are  described.  Systems  that  facilitate  these  processes  are 
described  as  points  of  potential  process  convergence.  To  take  best  advan¬ 
tage  of  the  points  of  process  convergence,  requirements  for  and  con¬ 
straints  changing  existing  procedures  are  described  in  the  last  section  of 
this  chapter. 

Private  sector  state  of  practice 

There  are  several  areas  where  work  on  commercial  projects  has  demon¬ 
strated  information  exchange.  This  section  reports  on  these  efforts  begin¬ 
ning  with  efforts  by  FIATECH  and  NIST  to  document  current  practices. 
Next,  a  brief  discussion  of  supply  chain  management  identifies  possible 
linkages  between  information  needed  to  purchase  and  install  materials, 
products,  equipment,  and  systems  and  the  handover  of  such  information. 

Life-cycle  information  exchange 

In  2002  EIATECH  surveyed  operations  and  maintenance  personnel  to  de¬ 
termine  their  perceived  need  for  information  exchange  from  contractors, 
suppliers,  and  manufacturers  in  the  process  industry  [Wood  2003].  There 
were  several  key  findings  from  this  study.  The  finding  first  was  that  struc¬ 
tural  and  information  technology  boundaries  separate  those  who  de¬ 
sign/build  from  those  who  operate  the  resulting  infrastructure.  The  diffi¬ 
culties  surrounding  the  use  of  legacy  information  technology  systems  that 
would  not  be  able  to  accept  automated  data  are  of  concern  to  employees  of 
large  firms.  A  significant  opportunity  for  streamlining  information  ex¬ 
change  exists  if  data  could  be  captured  during  design  and  construction 
then  viewed  during  operations  and  maintenance.  Finally,  construction 
project  deliverables  are  useful  for  operators;  however,  they  must  be  cur¬ 
rently  processed  by  hand  before  the  information  can  be  used. 
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The  FIATECH  study  confirms  that  (i)  the  types  of  information  currently 
provided  during  design  and  construction  are  helpful  for  operations  and 
maintenance  (O&M)  staff,  (2)  there  are  no  general  solutions  for  the  auto¬ 
mated  exchange  of  project  information  to  O&M,  and  (3)  if  there  existed  a 
method  to  directly  view  project  information  by  O&M  staff,  large  benefits 
would  be  accrued. 

In  2006  the  National  Institute  of  Standards  and  Technologies  and 
FIATECH  published  the  Capital  Facilities  Information  Handover  Guide, 
which  identifies  a  methodology  for  information  sharing  throughout  the 
facility  life-cycle  [Fallon  and  Palmer  2006].  The  four  stages  of  this  method 
are:  (1)  determine  the  business  cases  that  drive  the  capture  and  use  of 
building  information,  (2)  identify  specific  business  requirements  based  on 
these  cases  that  identify  what  information  should  be  captured,  (3)  create  a 
plan  for  the  handover  of  building  information,  and  (4)  implement  the 
handover  plan  using  both  improved  software  tools  and  augmented  busi¬ 
ness  processes.  While  the  Handover  Guide  is  focused  on  industrial  appli¬ 
cations,  many  of  the  same  issues  also  apply  to  infrastructure  and  tradi¬ 
tional  facility  construction.  These  issues  include  the  use  of  interoperable 
data  standards,  specification  of  exchange  requirements,  information  qual¬ 
ity  management,  and  information  retention  policies. 

The  Handover  Guide  recommends  the  use  of  industry  standard  formats 
such  as  the  IFC  model,  instead  of  proprietary  formats  since  future  system 
upgrades  may  not  be  able  to  read  data  from  previous  proprietary  formats. 
The  responsibility  and  methods  for  the  information  handover  must  be 
clearly  spelled  out  to  ensure  that  information  is  consistently  provided.  To 
insure  that  information  is  accurately  provided,  specific  content  and  timing 
of  information  transfer  should  also  be  specified.  Finally,  owners  should 
consider  how  they  will  ultimately  retain  and  augment  project  information 
throughout  the  facility  life-cycle.  Although  not  noted  in  the  NIST  survey, 
information  will  need  to  be  retained  even  past  demolition  to  ensure  infor¬ 
mation  is  available  for  potential  future  litigation. 

A  follow-on  report  from  NIST  for  non-industrial  facilities  [Fallon  2007] 
identifies  two  reasons  why  businesses  are  starting  to  adopt  BIM  technolo¬ 
gies.  The  first  reason  is  that  BIM  allows  the  creation  of  highly  accurate  de¬ 
sign  models  that  eliminate  field  changes  resulting  from  inaccurate  design 
coordination.  The  second  reason  is  that  improvements  in  communication 
with  team  members  regarding  construction  phasing  can  reduce  job  site 
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crew  friction.  Case  studies  in  the  NIST  report  document  these  findings  but 
note  that  the  benefits  achieved  have  limited  applicability  because  they  re¬ 
quire  vertically  integrated  stacks  of  software  for  all  team  members.  As  with 
the  original  “handover  guide,”  NIST  identifies  non-proprietary  software 
interoperability  as  a  critical  challenge  to  the  capital  facilities  industry.  The 
efforts  of  NBIMS  and  COBIE  are  specifically  identified  as  potentially  im¬ 
proving  software  interoperability  through  the  U.S.  adoption  of  Industry 
Foundation  Class  (IFC)  models  [Fallon  and  Palmer  2007]. 

Supply  chain  management 

While  owners  track  the  value  of  assets  installed  in  their  facilities,  those 
who  build  the  facilities  do  not  have  the  long-term  need  to  track  those  as¬ 
sets.  From  the  contractor’s  point  of  view,  those  building  components  are 
considered  part  of  a  supply  chain  that  ends  with  project  handover.  Corpo¬ 
rate  innovation  in  supply  chain  management  has  produced  such  major 
economic  powerhouses  as  Dell  Computers  and  Wal-Mart  stores.  Efforts  to 
study  the  impact  of  supply-chain  management  in  construction  have  been 
underway  for  approximately  a  decade. 

Efficiencies  gained  in  manufacturing  and  logistics  management  have  been 
achieved  by  aligning  the  objectives  of  suppliers  with  the  lead  organization 
[Tommelein  et  al.  2003].  Often  these  objectives  are  aligned  by  locking  in 
individual  suppliers  based  on  a  combination  of  price  and  performance. 
Unlike  manufacturing,  construction  is  driven  by  large  numbers  of  compa¬ 
nies  that  work  together  for  the  duration  of  a  construction  contract  [Shahid 
and  Froese  1998].  O’Brien  states  that  any  attempt  to  improve  the  process 
of  information  exchange  related  to  supply  chain  management  must  explic¬ 
itly  address  the  transient  nature  of  the  partnerships  and  production  in 
construction  [O’Brien  1999]. 

Adopting  processes  based  on  long-term  relationships  in  construction  con¬ 
tracting  are  not  a  realistic  ways  for  large  owners,  particularly  public  own¬ 
ers,  to  realize  the  benefits  of  contractor’s  supply  chain  management.  As  a 
result  approaches  other  than  “hard”  vertical  integration  or  “soft”  partner¬ 
ing  directions  must  be  explored.  Modeling  and  standardizing  stakeholder 
business  processes  may  substitute  for  vertical  integration  of  business  in¬ 
terests  [Vrijhoef  2001].  Unfortunately,  commercial  software  developers 
have  used  business  process  implementations  as  classic  business  “barriers 
to  entry”  that  keep  users  locked  into  proprietary  methods  of  accomplishing 
their  work  based  on  vendor-specific  feature  sets. 
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Association  efforts 

There  are  many  organizations  working  to  develop  information  standards 
related  to  data  that  may  be  applicable  for  COBIE.  The  first  two  subsections 
below  describe  relevant  technical  approaches  to  creating  standards  for 
COBIE  information  exchange.  The  conclusion  to  be  reached  through  the 
review  of  theses  two  technical  standards  is  that  regardless  of  the  final  deci¬ 
sions  on  the  information  exchange  content,  the  actual  implementation  of 
COBIE  in  terms  of  data  formats  required  must  be  a  hybrid  approach  that 
follows  the  building  construction  industries  current  practices. 

Eollowing  the  two  initial  sections,  several  projects  investigating  the  data 
requirements  for  building  industry  specific  information  exchanges  are  de¬ 
scribed.  This  section  of  the  report  concludes  with  the  description  of  a  not- 
for-profit  web  created  to  support  product-related  decision  making 
throughout  the  U.S.  construction  industry.  Information  on  exchange  stan¬ 
dards  for  structural  steel  (CIS/2)  and  sheet  metal  (ductXML)  were  not  in¬ 
cluded  in  this  report  because  those  standards  to  not  directly  relate  to 
COBIE  project  objectives. 

MIMOSA 

The  goals  of  the  Machinery  Information  Management  Open  Systems  Alli¬ 
ance  (MIMOSA)  organization  include  the  creation  of  open  information 
standards  for  life-cycle  asset  management  [Johnson  2004].  As  shown  in 
Table  2-1  [BP  2004],  MIMOSA  is  one  of  many  standards  that  have  been 
developed  for  the  exchange  of  information.  MIMOSA  began  as  a  standard 
for  the  communication  between  components  of  complex  military  systems 
and  later  included  participation  from  facility  management  organizations. 

MIMOSA  requires  the  identification  of  mechanical  assets  that  comprise 
complex  engineered  artifacts  for  such  diverse  industries  as  weapon  sys¬ 
tems,  process  plants,  and  heavy  industry.  The  MIMOSA  Common  Rela¬ 
tional  Information  Schema  (CRIS)  version  3.0  provides  relational  data¬ 
base  tables  to  capture  manufacturers,  asset  inventories,  system 
components,  condition  status,  and  associated  work  orders.  Members  of 
the  petrochemical  industry  currently  use  MIMOSA  standards  for  the  ex¬ 
change  of  product  information  supporting  a  range  of  supply  chain  activi¬ 
ties  [BP  2004]. 
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Table  2-1.  Data  exchange  standards  for  the  process  industry. 


Name 

Description 

Domains 

IS010303 

Step,  PIStep,  Epistle,  many  parts,  basis  of  other  stan¬ 
dards,  file  transfer  only 

Equipment  data 

IS015926 

httD://www.tcl84- 

sc4.org/wg3ndocs/wg3nl328/lifecvcle  integration  schema. ht 

Equipment  data 

ml 

MIMOSA 

OSA-EAI.  OSA-CBM.  www.mimosa.org 

Equipment  data 

OPC 

httoV/www.oDcfoundation.org/ 

Process  Data,  Embedded 
systems 

ISA  -  SP95 

httD://www.Dera.net/Standards/S95  Presentations/MESA  S9 

Production  planning  and 
Equipment  data 

5  fiies/frame.htm  and  httD://www.s95.ni/S95  02  en.htm 

B2MML 

httD://www.wbf.org/ 

Production  planning 

API690 

httD://www.Dera.net/Standards/API  Standards  nresentation/ 

Equipment  data 

API%20TF%20690%2001-20.Ddf 

API-689 

IS014224  -  see  above 

Operations  and  mainte¬ 
nance  data 

API-610 

See  above 

Procurement,  engineering, 
construction 

OASIS 

XML  onlv  transfer  of  PSLX  see  httoi/Zwww.oasis- 
ODen.org/committees/tc  home.DhD?wg  abbrev=DDS 

Production  planning 

OMG 

MfgDTF 

Object  Management  Group  -  Manufacturing  Domain 

Task  Force.  httD://www.omg.org/docs/mfg/01-06-06.Ddf 

Manufacturing  software 
components  interoperability 
via  CORBA 

IS0/TC184/ 

SC5 

JWG  8  (Manufacturing  Process  and  Management  Infor¬ 
mation  -  administered  by  ISO/TC  184/SC  4 

Of  particular  interest  to  the  building  sector  is  that  MIMOSA  has  been  cap¬ 
turing  manufacturer  nameplate  data  through  the  use  of  their  CRIS.  Analy¬ 
sis  of  the  format  for  nameplate  data  reflects  an  enterprise-view  of  the 
management  of  the  assets  needed  to  manage  the  production  of  large  scale 
industrial  activity  [Bever  2006].  Definition  of  individual  product  attributes 
is  not  prescribed,  but  supported  through  the  identification  of  complex 
types  that  provide  the  capacity  to  transfer  agreed  upon  characteristics  of 
the  equipment  being  provided.  This  highly  flexible  format  would  allow  the 
exchange  of  all  available,  or  provided  data,  for  any  type  of  equipment 
nameplate  data  needed.  The  benefit  to  such  an  approach  is  that  changes 
are  not  required  to  the  structure  of  the  data  to  represent  new  types  of 
equipment  or  modified  criteria. 

lAI 

The  goal  of  the  International  Alliance  for  Interoperability  (lAI)  is  to  de¬ 
velop  an  open-source  framework  for  exchange  of  facility  information 
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throughout  the  project  life-cycle  [lAI  2007].  The  model  produced  by  the 
lAI  is  the  Industry  Foundation  Class  (IFC)  model.  The  IFC  model  provides 
a  framework  for  information  exchange  and  is  able  to  describe  the  majority 
of  building  components,  processes,  and  interactions  from  many  different 
points  of  view. 

To  actually  apply  broad  model  frameworks  such  as  IFC  or  MIMOSA, 
agreements  as  to  the  ownership,  content,  and  timing  of  information  ex¬ 
changes  must  be  made  among  project  stakeholders.  These  agreements  are 
made  and  implemented  by  the  use  of  software  that  has  certified  they  sup¬ 
port  specific  information  exchanges.  The  IFC  model  explicitly  identifies 
conceptual  and  physical  object  identities,  ownership,  and  history  allowing 
such  information  to  be  tracked  through  the  planning,  design,  construction, 
contacting,  operational,  and  disposal/refractoring  stages. 

To  evaluate  the  use  of  the  IFC  model  for  applicability  to  the  building  con¬ 
struction  industry  exchange  of  product  information  a  review  of  version 
2x2  was  conducted  and  related  information  relevant  to  equipment  data 
has  been  extracted,  as  described  in  the  following  sections.  The  information 
provided  in  the  following  is  abstracted  from  the  IFC  model  with  respect  to 
the  data  needed  for  near-term  COBIE  efforts. 

Structural  system  and  miscellaneous  components 

In  the  IFC  model  structural  system  components  (see  Table  2-2)  are  de¬ 
fined  by  their  placement  and  physical  representation  with  a  given  facility. 
Specific  attributes  of  these  components  are  provided  by  related  enumera¬ 
tions  or  property  sets.  In  general,  the  definition  of  such  components  for 
COBIE  is  a  secondary  issue  whose  primary  interest  is  in  future  reuse,  re¬ 
design,  or  recycling  of  a  facility. 

During  construction,  representations  of  structural  components  are  pro¬ 
vided  through  shop  drawings,  fabrication,  and  erection  details.  It  is  not  the 
intent  of  COBIE  to  require  such  information  in  lEC  format.  Construction 
required  construction  submittals  will,  however,  be  identified  within 
COBIE  but  not  linked  to  specific  lEC  objects  the  existence  of  which  and 
utility  of  is  far  from  certain. 
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Table  2-2.  Structural  system  and  miscellaneous  component  entities. 


Moisture  protection  component  attributes 

Of  critical  concern  to  facility  operators  are  moisture  protection  compo¬ 
nents  such  as  roofing.  Anecdotal  evidence  suggests  that  the  primary  cause 
of  building  failure  is  moisture  intrusion.  Within  the  IFC  mode  the  IfcRoof 
element  identifies  the  shape  and  placement  of  the  roof  only.  Specific  at¬ 
tributes  are  explicitly  identified  in  the  IFC  model.  Such  information  may, 
however,  be  attached  as  property  sets  within  an  IFC  compliant  file. 

Door  and  window  component  attributes 

Within  the  IFC  model  extensive  design-related  information  is  provided  for 
doors  and  windows.  This  information  is  provided  below  for  the  reader  to 
review.  Given  that  much  of  the  focus  of  the  creation  of  the  IFC  model  has 
been  on  the  design  and  geometry  of  these  components,  only  some  of  the 
information  identified  in  the  IFC  model  need  be  referenced  in  COBIE.  The 
data  required  by  the  IFC  model  for  Doors  and  Windows,  and  its  data  type 
are  provided  below  (Table  2-3  -  Table  2-10). 


Table  2-3.  IfcDoor. 


Field  Name 

Data  Type 

Size 

OverallHeight 

Number 

Double 

OverallWidth 

Number 

Double 
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Table  2-4.  IfcDoorLiningProperties. 


Field  Name 

Data  Type 

Size 

LiningDepth 

Number 

Double 

LiningThickness 

Number 

Double 

ThresholdDepth 

Number 

Double 

ThresholdThickness 

Number 

Double 

TransomThickness 

Number 

Double 

TransomOffset 

Number 

Double 

LiningOffset 

Number 

Double 

Threshold  Offset 

Number 

Double 

CasingThickness 

Number 

Double 

CasingDepth 

Number 

Double 

ShapeAspectStyle 

Text 

50 

Table  2-5.  IfcDoorPanelProperties. 


Field  Name 

Data  Type 

Size 

PanelDepth 

Number 

Double 

PanelOperation 

Text 

50 

PanelWidth 

Number 

Double 

PanelPosition 

Text 

50 

ShapeAspectStyle 

Text 

50 

Table  2-6.  IfcDoorStyle. 


Field  Name 

Data  Type 

Size 

OperationType 

Text 

50 

ConstructionType 

Text 

50 

ParameterTakesPrecedence 

Yes/ No 

- 

Sizeable 

Yes/ No 

- 

Table  2-7.  IfcWIndow. 


Field  Name 

Data  Type 

Size 

OverallHeight 

Number 

Double 

OverallWidth 

Number 

Double 
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Table  2-8.  IfcWindowLiningProperties. 


Field  Name 

Data  Type 

Size 

LiningDepth 

Number 

Double 

LiningThickness 

Number 

Double 

TransomThickness 

Number 

Double 

MullionThickness 

Number 

Double 

TransomThickness 

Number 

Double 

Fi  rstTra  n  so  m  Offset 

Number 

Double 

SecondTransomOffset 

Number 

Double 

FirstMul  lion  Off  set 

Number 

Double 

SecondMullionOffset 

Number 

Double 

ShapeAspectStyle 

Text 

50 

Table  2-9.  IfcWindowPanelProperties. 


Field  Name 

Data  Type 

Size 

OperationType 

Text 

50 

FrameDepth 

Number 

Double 

FrameThickness 

Number 

Double 

PanelPosition 

Text 

50 

ShapeAspectStyle 

Text 

50 

Table  2-10.  IfcWIndowStyle. 


Field  Name 

Data  Type 

Size 

OperationType 

Text 

50 

ConstructionType 

Text 

50 

ParameterTakesPrecedence 

Yes/ No 

- 

Sizeable 

Yes/ No 

- 

Mechanical  system  component  attributes 

Mechanical  equipment  components  make  up  the  bulk  of  information  cur¬ 
rently  required  for  facility  maintenance.  Anecdotally,  mechanical  system 
failures  are  the  primary  cause  of  preventative  maintenance,  service  orders, 
and  work  orders.  The  IFC  model  reflects  the  richness  of  information 
needed  for  the  design  of  mechanical  components,  as  shown  in  Table  2-11  - 
Table  2-26.  Those  aspects  of  mechanical  systems  that  support  asset  man¬ 
agement,  operations,  and  facility  maintenance  should  be  required  by  the 
COBIE  specification. 
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Table  2-11.  IfcAirFilters. 


Field  Name 

Data  Type 

Size 

DirtyPressureDrop 

Number 

Double 

CleanPressureDrop 

Number 

Double 

Efficiency 

Number 

Double 

Table  2-12.  IfcAirTerminal. 


Field  Name 

Data  Type 

Size 

AirFlowType 

Text 

50 

Throw 

Number 

Double 

AirDiffusionPerformanceIndex 

Number 

Double 

FinishType 

Text 

50 

FinishColor 

Memo 

- 

MountingType 

Text 

50 

FaceType 

Text 

50 

CoreType 

Text 

50 

CoreSetVertical 

Number 

Double 

CoreSetHorizontal 

Number 

Double 

IntegralControl 

Yes/ No 

- 

Table  2-13.  IfcAIrTermlnalBox. 


Field  Name 

Data  Type 

Size 

TerminalBoxType 

Text 

50 

SoundLevel 

Text 

50 

Table  2-14.  IfcBoller. 


Field  Name 

Data  Type 

Size 

HeatTransferRate 

Number 

Double 

ThermalEfficiency 

Number 

Double 

PrimaryEnergySource 

Text 

50 

BoilerType 

Text 

50 

HeatOutput 

Number 

Double 

PressureRating 

Number 

Double 

EnergyInputRate 

Number 

Double 
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Table  2-15.  IfcChiller. 


Field  Name 

Data  Type 

Size 

HeatTransferRate 

Number 

Double 

ThermalEfficiency 

Number 

Double 

PrimaryEnergySource 

Text 

50 

ChillerType 

Text 

50 

NominalCoolingCapacity 

Number 

Double 

Table  2-16.  IfcCoil. 


Field  Name 

Data  Type 

Size 

CoilType 

Text 

50 

BypassFactor 

Number 

Double 

FaceVelocity 

Number 

Double 

FlowArrangement 

Text 

50 

Table  2-17.  IfcCom pressor. 


Field  Name 

Data  Type 

Size 

PrimaryEnergySource 

Text 

50 

ImpellerDiameter 

Number 

Doubie 

CompressorType 

Text 

50 

HotGasBypass 

Yes/ No 

- 

Table  2-18.  IfcCoolin^ower. 


Field  Name 

Data  Type 

Size 

HeatTransferRate 

Number 

Double 

ThermalEfficiency 

Number 

Double 

PrimaryEnergySource 

Text 

50 

CoolingTowerType 

Text 

50 

Table  2-19.  ifcDamper. 


Field  Name 

Data  Type 

Size 

PredefinedType 

Text 

50 

FrameDepth 

Number 

Double 

SizingMethod 

Text 

50 

Cl  oseOff  Rating 

Number 

Double 

Lea  kageAirFI  owRate 

Number 

Double 

PercentOpen 

Number 

Double 
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Table  2-20.  ifcFan. 


Field  Name 

Data  Type 

Size 

PrimaryEnergySource 

Text 

50 

ImpellerDiameter 

Number 

Double 

AirFlowType 

Text 

50 

StaticPressure 

Number 

Double 

FanPressureClass 

Text 

50 

FanWheelType 

Text 

50 

WheelMaterial 

Text 

50 

WheelTipSpeed 

Number 

Double 

DischargeVelocity 

Number 

Double 

HousingMaterial 

Text 

50 

DischargePressureLoss 

Number 

Double 

FanDischargeType 

Text 

50 

FanArrangement 

Text 

50 

FanRotation 

Text 

50 

FanDriveArrangement 

Text 

50 

DrivePowerLoss 

Number 

Double 

MotorDriveType 

Text 

50 

MotorInAirstream 

Yes/ No 

- 

FanMountingType 

Text 

50 

Table  2-21.  IfcHeatExchanger. 


Field  Name 

Data  Type 

Size 

HeatTransferRate 

Number 

Double 

ThermalEfficiency 

Number 

Double 

PrimaryEnergySource 

Text 

50 

HeatExchangerType 

Text 

50 

HeatExchangerArrangement 

Text 

50 

NumberOfPlates 

Number 

Double 

Table  2-22.  IfcPump 


Field  Name 

Data  Type 

Size 

PrimaryEnergySource 

Text 

50 

ImpellerDiameter 

Number 

Double 

PumpType 

Text 

50 

NetPositiveSuctionHead 

Number 

Double 

ImpellerSealMaterial 

Text 

50 

PumpBaseType 

Text 

50 

MotorDriveType 

Text 

50 
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Table  2-23.  IfcSensor. 


Field  Name 

Data  Type 

Size 

ControlElementId 

Memo 

- 

PredefinedType 

Text 

50 

Table  2-24.  IfcTank 


Field  Name 

Data  Type 

Size 

Volume 

Number 

Double 

ReliefValveSetting 

Number 

Double 

Pressu  reRegu  latorSetti  ng 

Number 

Double 

Table  2-25.  IfcUnitHeater. 


Field  Name 

Data  Type 

Size 

HeatTransferRate 

Number 

Double 

ThermalEfficiency 

Number 

Double 

PrimaryEnergySource 

Text 

50 

Table  2-26.  IfcValve. 


Field  Name 

Data  Type 

Size 

Cl  oseOff  Rating 

Number 

Double 

ValveFlowCoefficient 

Text 

50 

ValveType 

Text 

50 

Additional  information  about  the  specific  installation  of  components  will 
be  needed  for  COBIE.  Attributes  such  as  a  specific  valves  Valve  Tag  and 
room  in  which  a  specific  valve  tags  are  located  will  be  required.  The  spe¬ 
cific  implementation  of  these  relational  entities  is  discussed  later  in  this 
report. 

Electrical  system  component  attributes 

Electrical  components  in  lECs  were  also  considered  in  depth.  The  attrib¬ 
utes,  mostly  associated  with  the  design  of  such  objects,  are  identified  in 
Table  2-27  -  Table  2-31.  General  electrical  components,  such  as  appliances 
and  outlets,  due  to  their  generality,  have  relatively  few  attributes.  Specific 
types  of  equipment  are  defined  with  multiple  attributes. 


Table  2-27.  IfcAppllance. 


Field  Name 

Data  Type 

Size 

ApplianceType 

Text 

50 
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Table  2-28.  IfcElectricalExtendedProperties. 


Field  Name 

Data  Type 

Size 

ElectricCurrentType 

Text 

50 

InputVoltage 

Number 

Double 

InputFrequency 

Number 

Double 

FullLoadCurrent 

Number 

Double 

MinimumCircuitCurrent 

Number 

Double 

MaximumPowerInput 

Number 

Double 

RatedPowerInput 

Number 

Double 

InputPhase 

Number 

Double 

InrushCurrent 

Number 

Double 

LockedRotorCurrent 

Number 

Double 

CircuitSizePowerInput 

Number 

Double 

FuseSize 

Number 

Double 

Grounded 

Yes/ No 

- 

Table  2-29.  IfcElectricalMotor. 


Field  Name 

Data  Type 

Size 

MotorWindingType 

Text 

50 

Efficiency 

Number 

Doubie 

PowerOutput 

Number 

Doubie 

FrameConfiguration 

Memo 

- 

InsuiationRating 

Memo 

- 

MotorHousing 

Text 

50 

Table  2-30.  IfcLIghtFixtures. 


Field  Name 

Data  Type 

Size 

MaximumSpaceSensibleLoad 

Number 

Double 

MaximumPlenumSensibleLoad 

Number 

Double 

SensibleLoadToRadiant 

Number 

Double 

Table  2-31.  IfcOutlet. 


Field  Name 

Data  Type 

Size 

OutletType 

Text 

50 

IFC  property  sets 

In  addition  to  the  explicit  attributes  of  objects  identified  in  the  IFC  model, 
there  are  also  large  numbers  of  “property  sets”  that  define  specific  types  of 
information  associated  with  specific  IFC  objects.  Separating  the  property 
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sets  from  the  actual  objects  allows  the  IFC  model  to  provide  a  more  exten¬ 
sible  data  standard. 

The  specific  property  sets  that  relate  to  information  needed  for  materials, 
products,  equipment,  and  systems  that  are  part  of  the  submittal  process 
have  been  extracted  from  the  IFC  model  and  listed  in  Table  2-32  -  Table 
2-36.  Note  that  for  readability,  the  “PSet_”  prefix  found  on  all  IFC  prop¬ 
erty  sets  has  been  removed  from  the  set  titles  shown  below.  Readers  are 
encouraged  to  review  the  IFC  model  to  review  the  specifics  of  these  prop¬ 
erty  sets. 


Table  2-32.  Property  set:  Electrical  Extensions. 


Property  Set  Name 

Related  ifcObject 

CoveringCommon 

IfcCovering,  IfcCovering- 
Type 

Coveringceiling 

IfcCovering 

CoveringFlooring 

IfcCovering 

Table  2-33.  Property  set:  Shared  Elements. 


Property  Set  Name 

Related  ifcObject 

DoorCommon 

IfcDoor 

DoorWindowGIazingType 

IfcDoor,  IfcWindow 

DoorWindowShadingType 

IfcDoor,  IfcWindow 

WindowCommon 

IfcWindow 

Table  2-34.  Property  set:  Shared  Building  Services  Elements. 


Property  Set  Name 

Related  ifcObject 

FlowMovingDeviceCompressor 

IfcFlowMovingDevice 

FlowMovingDeviceFan 

If  cFI  owM  ovi  ngDevi  ce 

FlowMovingDeviceFanCentrifugal 

If  cFI  owM  ovi  ngDevice 

FlowMovingDevicePump 

IfcFlowMovingDevice 

Table  2-35.  Property  set:  Shared  Facilities  Elements. 


Property  Set  Name 

Related  ifcObject 

Warranty 

IfcProduct,  IfcSystem 
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Table  2-36.  Property  set:  Building  Controls  Domain. 


Property  Set  Name 

Related  ifcObject 

ActuatorTypeCommon 

IfcActuatorType 

Actu  atorTy  pe  Li  n  ea  rActu  atio  n 

IfcActuatorType 

ActuatorTypeRotationalActuation 

IfcActuatorType 

ActuatorTypeElectricActuator 

IfcActuatorType 

Actu  atorTy  pe  H  yd  ra  u  1  i  cActuator 

IfcActuatorType 

ActuatorTypePneumaticActuator 

IfcActuatorType 

FlowInstrumentTypeThermometer 

IfcFlowInstrumentType 

FlowInstrumentTypePressureGauge 

IfcFlowInstrumentType 

SensorTypeC02Sensor 

IfcSensorType 

SensorTypeFireSensor 

IfcSensorType 

SensorTypeGasSensor 

IfcSensorType 

SensorTypeHeatSensor 

IfcSensorType 

SensorTypeHumiditySensor 

IfcSensorType 

SensorTypeLightSensor 

IfcSensorType 

SensorTypeMovementSensor 

IfcSensorType 

SensorTypePressureSensor 

IfcSensorType 

SensorTypeSmokeSensor 

IfcSensorType 

SensorTypeSoundSensor 

IfcSensorType 

SensorTypeTemperatureSensor 

IfcSensorType 

The  Building  Controls  Domain  table  (Table  2-36)  demonstrates  that  gen¬ 
eral  IFC  objects  are  applied  to  specific  facilities  through  the  creation  and 
linking  of  specific  property  sets  for  individual  entities. 


The  IFC  model  also  contains  property  sets  for  items  related  electrical  ob¬ 
jects.  These  items  are  noted  in  Table  2-37. 
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Table  2-37.  Property  set:  Electrical  Domain. 


Property  Set  Name 

Related  ifcObject 

ElectricalDeviceCommon 

ElectricGeneratorTypeCommon 

IfcElectricGeneratorType 

ElectricMotorTypeCommon 

IfcElectricMotorType,  If- 
cFlowMovingDeviceType 

ElectricHeaterTypeElectricalPointH  eater 

If  cEI  ectricFI  eaterType 

ElectricHeaterTypeElectricalCableHeater 

IfcElectricFleaterType 

ElectricHeaterTypeElectricalMatH  eater 

If  cElectricFI  eaterType 

LampEmitterTypeCommon 

IfcLampType 

LightFixtureTypeCommon 

IfcLightFixtureType 

OutletTypeCommon 

IfcOutletType 

ProtectiveDeviceTypeCommon 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeCircuitBreaker 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeEarthFailureDevice 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeFuseDisconnector 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeResidualCurrentCircuit- 

Breaker 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeResidualCurrentSwitch 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeVaristor 

IfcProtectiveDeviceType 

ProtectiveDeviceTypeVaristor 

IfcProtectiveDeviceType 

SwitchingDeviceTypeContactor 

IfcProtectiveDeviceType 

SwitchingDeviceCommon 

IfcSwitchingDeviceType 

SwitchingDeviceTypeEmergencyStop 

IfcSwitchingDeviceType 

Switch  i  ngDevi  ceTy  peSta  rter 

IfcSwitch  ingDeviceType 

SwitchingDeviceTypeSwitchDisconnector 

IfcSwitchingDeviceType 

SwitchingDeviceTypeToggleSwitch 

IfcSwitchingDeviceType 

TransformerTypeCommon 

IfcTransformerType 

HVAC  domain  property  sets  (Table  2-38  -  Table  2-41)  have  been  sepa¬ 
rated,  for  the  purposes  of  presentation,  into  (1)  property  sets  related  to 
HVAC  components  that  may  or  may  not  be  submitted  as  separate  items, 
(2)  HVAC  equipment,  and  (3)  valves.  While  these  distinctions  may  not  be 
entirely  correct,  it  may  be  useful  to  separate,  for  the  purposes  of  COBIE 
the  level  of  detail  needed  to  support  compliance  with  performance  specifi¬ 
cations  versus  the  level  of  detail  needed  to  evaluate  mechanical  engineer¬ 
ing  system  designs. 
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Table  2-38.  Property  set:  HVAC  Domain  (Components). 


Property  Set  Name 

Related  ifcObject 

AirTerminalBoxTypeCommon 

IfcAirTerminalBoxType 

AirTerminalTypeCommon 

IfcAirTerminalType 

AirToAirHeatRecoveryTypeCommon 

IfcAi  rToAi  rH  eatRecoveryTy  pe 

EvaporativeCoolerTypeCommon 

IfcEvaporativeCoolerType 

EvaporatorTypeCommon 

IfcEvaporatorType 

FilterTypeAirParticleFilter 

IfcFilterType 

FilterTypeCommon 

IfcFilterType 

FlowMeterTypeCommon 

IfcFlowMeterType 

FlowMeterTypeEnergyMeter 

IfcFlowMeterType 

FlowMeterTypeGasMeter 

IfcFlowMeterType 

FlowMeterTypeOilMeter 

IfcFlowMeterType 

FI  owM  eterTy  peWaterM  eter 

IfcFlowMeterType 

TubeBundleTypeCommon 

IfcTubeBundleType 

TubeBundleTypeFinned 

IfcTubeBundleType 

VibrationIsolatorTypeCommon 

IfcVibrationIsolatorType 
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Table  2-39.  Property  set:  HVAC  Domain  (Equipment). 


Property  Set  Name 

Related  ifcObject 

BoilerTypeCommon 

IfcBoilerType 

BoilerTypeSteam 

IfcBoilerType 

ChillerTypeCommon 

IfcChillerType 

CoilTypeCommon 

IfcCoilType 

CompressorTypeCommon 

IfcCompressorType 

CondenserTypeCommon 

IfcCondenserType 

CoolingTowerTypeCommon 

IfcCoolingTowerType 

DamperTypeCommon 

IfcDamperType 

DamperTypeControlDamper 

IfcDamperType 

DamperTypeFireDamper 

IfcDamperType 

DamperTypeFireSmokeDamper 

IfcDamperType 

DamperTypeSmokeDamper 

IfcDamperType 

FanTypeCommon 

IfcFanType 

FanTypeSmokeControl 

IfcFanType 

GasTerminalTypeCommon 

IfcGasTerminalType 

GasTerminalTypeGasAppliance 

IfcGasTerminalType 

GasTerminalTypeGasBurner 

IfcGasTerminalType 

FleatExchangerTypeCommon 

IfcFleatExchangerType 

FleatExchangerTypePlate 

IfcFleatExchangerType 

FlumidifierTypeCommon 

IfcFlumidifierType 

PumpTypeCommon 

IfcPumpType 

SpaceFleaterTypeCommon 

IfcSpaceFleaterType 

SpaceFleaterTypeFlydronic 

IfcSpaceFleaterType 

TankTypeCommon 

IfcTankType 

TankTypeExpansion 

IfcTankType 

TankTypePreformed 

IfcTankType 

TankTypePressureVessel 

IfcTankType 

TankTypeSectional 

IfcTankType 

UnitaryEquipmentTypeAirConditioningUnit 

IfcUnitaryEquipmentType 

UnitaryEquipmentTypeAirFlandler 

IfcUnitaryEquipmentType 

ERDC/CERLTR-07-30 


26 


Table  2-40.  Property  set:  HVAC  Domain  (Valves). 


Property  Set  Name 

Related  ifcObject 

ValveTypeAirRelease 

IfcValveType 

ValveTypeCommon 

IfcValveType 

ValveTypeDrawOffCock 

IfcValveType 

ValveTypeFaucet 

IfcValveType 

ValveTypeFlushing 

IfcValveType 

ValveTypeGasTap 

IfcValveType 

ValveTypelsolating 

IfcValveType 

ValveTypeMixing 

IfcValveType 

ValveTypePressureReducing 

IfcValveType 

ValveTypePressureRelief 

IfcValveType 

VibrationIsolatorTypeCommon 

IfcVibrationIsolatorType 

Table  2-41.  Property  set:  Plumbing  Fire  Protection. 


Property  Set  Name 

Related  ifcObject 

DrainageCulvert 

IfcSystem 

FireSuppressionTerminalTypeBreechingInlet 

IfcFireSuppressionTerminalType 

FireSuppressionTerminalTypeFireHydrant 

IfcFireSuppressionTerminalType 

FireSuppressionTerminalTypeSprinkler 

IfcFireSuppressionTerminalType 

FireSuppressionTerminalTypeHoseReel 

IfcFireSuppressionTerminalType 

SanitaryTerminalTypeBath 

IfcSanitaryTerminalType 

SanitaryTerminalTypeBidet 

IfcSanitaryTerminalType 

SanitaryTerminalTypeCistern 

If  cSa  n  ita  ryTerm  i  na  IType 

SanitaryTerminalTypeSanitaryFountain 

IfcSanitaryTerminalType 

SanitaryTerminalTypeShower 

IfcSanitaryTerminalType 

SanitaryTerminalTypeSink 

IfcSanitaryTerminalType 

SanitaryTerminalTypeToiletPan 

If  cSa  nitaryTerminalType 

SanitaryTerminalTypeUrinal 

If  cSa  n  ita  ryTe  r  m  i  n  a  ITy  pe 

SanitaryTerminalTypeWCSeat 

IfcSanitaryTerminalType 

SanitaryTerminalTypeWashHandBasin 

IfcSanitaryTerminalType 

WasteTerminalTypeFloorTrap 

IfcWasteTerminalType 

WasteTerminalTypeFloorWaste 

IfcWasteTerminalType 

WasteTerminalTypeGreaseInterceptor 

IfcWasteTerminalType 

WasteTerminalTypeGullySump 

IfcWasteTerminalType 

WasteTerminalTypeGullyTrap 

IfcWasteTerminalType 

WasteTerminalTypeOilInterceptor 

IfcWasteTerminalType 

WasteTe  r  m  i  n  a  ITy  pe  Petro  1 1  nterce  pto  r 

IfcWasteTerminalType 

WasteTerminalTypeRoofDrain 

IfcWasteTerminalType 

WasteTerminalTypeWasteDisposalUnit 

IfcWasteTerminalType 

WasteTerminalTypeWasteTrap 

IfcWasteTerminalType 
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To  represent  a  given  item,  such  as  pump  within  the  IFC  model  many  dif¬ 
ferent  types  of  data  may  be  provided.  For  example  the  design  parameters 
required  by  the  pump  may  be  identified  by  property  sets,  the  location  of 
the  pump  may  be  identified,  and  the  geometry  of  the  pump  itself  may  all 
be  modeled.  The  agreement  of  what  data  in  the  IFC  model  is  needed  de¬ 
pends  on  the  use-cases  for  the  data.  In  the  case  of  submittal  review,  the 
specific  pump  is  an  instance  of  an  IfcFlowMovingDevice.  The  object  has  a 
specific  value  of  the  IfcPumpTypeEnum  which  links  a  required  property 
sets  for  both  PumpTypeCommon  and  for  the  specific  type  of  pump  identi¬ 
fied  in  the  IfcPumpTypeEnum. 

IFC-mBomb  Project 

The  goal  of  the  mBomb  project  was  to  determine  the  extent  to  which 
commercial  software  could  support  the  exchange  of  design  related  infor¬ 
mation  through  construction  into  operations  [Stephens  2005].  The  results 
from  this  project  demonstrated  that  significant  translation  efforts  remain 
with  regard  to  commercial  software  systems. 

IFC-PM3  information  specification 

The  goal  of  the  PM3  project  was  to  identify  data  structures  necessary  for 
the  use  of  product  information  in  (1)  specifying  products  during  design, 

(2)  selecting  products  during  bidding,  (3)  compare  expected  or  installed 
properties  of  products  to  initial  product  requirements,  and  (4)  and  selec¬ 
tion  of  replacement  equipment  during  facility  operations  [Grobler  2002]. 
One  of  the  contributions  of  the  PM3  project  was  to  identify  the  use  of  the 
IfcConstraint  object  as  the  entity  that  should  be  used  to  capture  specific 
requirements  needed  to  specify  installed  equipment.  PM3  did  not,  how¬ 
ever,  identify  the  set  of  requirements  needed  for  such  specifications. 

ifcXML 

There  are  several  different  ways  to  present  lEC  model  data.  One  standard 
method  for  the  exchange  of  full  lEC  models  is  the  “EXPRESS”  language. 
Express  files  are  ASCII  files  that  contain  building  models  in  very  compact 
format  and  allow  the  identification  of  entity  relationships  that  allow  data 
to  be  re-indexed  when  the  information  is  loaded  back  into  a  building 
model  server  or  other  lEC-compliant  software  tool. 
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Another  way  to  provide  IFC  data  is  through  an  XML  file.  The  ifcXML  for¬ 
mat  has  been  developed  to  provide  means  for  transfer  of  discrete  parts  of 
Building  Information  Models  [Nisbet  and  Liebich  2005].  Using  the 
ifcXML  specification  methods  to  represent  building  elements  and  related 
property  sets  can  be  easily  created.  An  example  of  the  ifcXML  related  to 
product  catalogs  provides  a  very  good  example  of  a  method  for  informa¬ 
tion  exchange  where  the  detailed  attributes  of  the  given  component  are 
explicitly  identified. 

aecXML 

The  aecXML  effort  is  currently  identified  as  a  project  whose  goal  is  to 
promote  the  adoption  if  ifcXML  schemas  within  the  building  industry 
[aecXML  2006].  There  are  several  ongoing  development  activities  of  the 
aecXML  group,  but  these  do  not  currently  overlap  with  the  COBIE  effort. 

OmniClass 

The  OmniClass  effort  is  an  ISO  standards  compliant,  comprehensive, 
open-source  taxonomy  for  the  (primarily)  North  American  construction 
industry  [OCCS  2006].  Consistent  application  of  the  OmniClass  scheme  to 
project  data  ensures  that  project  team  members  are  able  to  reference  and 
retrieve  related  information  in  the  future.  The  U.S.  National  Building  In¬ 
formation  Modeling  Standard  has  expressed  its  interest  in  adopting  Om¬ 
niClass  as  its  standard  taxonomy  to  be  used  in  conjunction  with  the  IFC 
Model. 

NIBS  ProductGuide 

The  National  Institute  of  Building  Sciences  ProductGuide  is  an  electronic 
library  of  information  that  defines  standards  needed  for  individual  prod¬ 
ucts  as  specified  in  the  UFGS.  These  product  data  sheets  allow  manufac¬ 
turers  to  certify  the  standards  met  by  the  individual  products. 

While  general  product  information  contained  in  building  codes  provides 
only  minimal  performance  requirements,  the  attributes  of  products  that 
are  required  by  individual  standards  testing  bodies  are  very  specific.  The 
objective  of  reviewing  the  ProductGuide  data  sheets  is  to  investigate  the 
information  needed  for  testing  agency  requirements.  Table  2-42  shows  the 
requirement  for  data  attributes  extracted  from  standards  referenced  in 
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UFGS  07212,  “Mineral  Fiber  Blanket  Insulation,”  for  the  properties  of  the 
insulation. 


Table  2-42.  Insulation  attributes  required  for  certification. 


Standard 

Attribute 

Value  Range 

ASTM  C  665 

MadeOf 

Rock  Wool 

Fiberglass 

Asbestos 

ASTM  C  665 

CoveredBy 

NoCovering 

NonReflectiveMembrane 

ReflectiveMembrane 

ASTM  E  84 

FlameSpread 

<25 

25  to  <75 

75  to  100 

ASTM  E  84 

SmokeSpread 

<150 

150  or  greater 

Table  2-43  defines  the  properties  that  are  required  for  the  certification  of 
accessory  materials  used  with  mineral  fiber  insulation.  Given  the  differ¬ 
ences  in  types  of  materials  used,  there  are  a  wide  variety  of  test  require¬ 
ments  for  this  set  of  products.  Discussion  with  NIBS  staff  regarding  manu¬ 
facturer’s  acceptance  of  the  ProductGuide  has  indicated  that  many 
manufacturer’s  representatives  do  not  have  access  to  testing  reports,  may 
not  be  aware  of  tests  that  were  accomplished,  or  have  completed  previous 
or  later  tests  than  those  explicitly  identified  by  specification. 
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Table  2-43.  Insulation  accessory  attributes. 


Standard 

Accessory 

Attribute 

ASTM  C  665 

SillSealerInsulation 

ASTM  C  665 

Blocking 

Covers 

ASTM  C665 

VaporRetarder 

MadeOf 

ASTM  E  96 

Permeance 

ASTM  E  84 

FlameSpread 

ASTM  E  136 

CombustionProducts 

TAPPI  T803  CM 

PunctureResistance 

ASTM  D  828 

TensileStrenth 

ASTM  C  665 

Pressure  Sensitive  Tape 

ManufactuerApprovedList 

ASTM  E  96 

Permeance 

Adhesives 

ManufactuerApprovedList 

Mechanical  Fasteners 

CorrosionResistant 

ManufactuerApprovedList 

Wire  Mesh 

CorrosionResistant 

ManufactuerApprovedList 

Specifiers’  property  set  project 

Unfortunately,  manufacturers’  property  set  information  today  is  typically 
stored  not  as  editable  alphanumeric  information,  but  as  graphical  images 
of  paper  documents  archived  in  Portable  Document  Format  (PDF)  files.  As 
such,  the  captured  information  cannot  be  processed  directly  by  computer 
programs.  Studies  at  the  University  of  Illinois  and  ERDC  resulted  in  an 
initiative  to  start  a  new  NBIMS  Development  Team  project  related  to  the 
specification  of  product  property  sets  (scheduled  to  begin  in  December 
2007).  Project  participants  are  the  Specifications  Consultants  in  Inde¬ 
pendent  Practice  (SCIP),  the  Construction  Specifications  Institute  (CSI), 
and  ERDC.  The  specification  will  identify  the  attributes  of  materials, 
products,  and  equipment  as  used  by  specifiers  within  the  schematic  de¬ 
sign,  design  development,  and  construction  documents  design  phase.  The 
objectives  of  this  project  include: 

Property  Sets  Definition.  This  project  will  identify  the  full  set  of  properties 
needed  to  specify  materials,  products,  and  equipment  to  a  “typical”  level  of 
detail.  Additional  levels  of  details  for  multiple  subcomponents  may  be  in¬ 
cluded  in  future  iterations  of  this  project  once  a  “breadth-first”  view  of  ma¬ 
terials,  products,  and  equipment  has  been  defined. 
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Property  Set  Processes  Maps.  This  project  will  identify  who  is  responsible 
for  identifying  the  requirement  for  property  sets,  general  classes  of  proper¬ 
ties,  type  of  property  specifications,  and  specific  property  values.  This  ob¬ 
jective  fulfills  the  first  step  of  the  Information  Delivery  Manual  process. 

Property  Set  Exchange  Requirements.  This  project  will  identify  when  spe¬ 
cific  data  need  to  be  exchanged  at  specific  points  within  the  Property  Set 
Process  Maps.  Given  the  number  of  different  specification  methods  and 
differences  in  practice,  the  project  team  will  focus  on  several  representa¬ 
tive  methods  and  practices. 

Property  Set  Models.  This  project  will  map  the  specifiers’  property  set  re¬ 
quirements  to  the  IFC  2x3  Model.  Additional  implementation  methods  in¬ 
cluding,  but  not  limited  to,  user-fillable  PDF  forms,  XML  schema,  and 
spreadsheet  formats  may  also  be  considered  to  assist  the  exchange  of  this 
information. 

Dictionary.  This  project  will  compile  the  properties  identified  and  provide 
them  to  the  Construction  Specification  Institute  for  coordination  with  the 
International  Framework  for  Dictionary  (IFD)  classification  scheme 
through  the  OmniClass  classification  scheme.  OmniClass  classification,  as 
the  United  States  facing  view  of  the  IFD,  will  work  to  include  the  proper¬ 
ties  within  the  OmniClass  taxonomy. 

Commercial  Adoption.  While  adoption  by  public-sector  stakeholders  can 
be  expected  as  a  result  of  this  project,  widespread  industry  acceptance  will 
ultimately  depend  on  commercial  support  of  the  properties  and  exchange 
methods  identified  in  this  project  by  product  manufacturers  and  service 
providers. 

Given  the  objectives  of  the  specifiers’  property  set,  the  author  and  several 
sponsors  are  expected  to  support  this  project  into  Fiscal  Year  (FY)  08,  with 
direct  coordination  with  manufacturers  initiated  in  FY09. 

Public  sector  state-of-practice 

In  the  U.S.  public  sector  there  are  two  types  of  information  required  at  the 
end  of  construction.  The  first  type  of  information  captures  the  set  of  in¬ 
formation  that  is  needed  for  system  maintainers.  The  second  type  of  in¬ 
formation  captures  the  set  of  information  needed  for  agency  asset  manag¬ 
ers.  Two  examples  of  information  exchanges  for  maintenance  are  provided 
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in  the  following  paragraphs.  Following  the  examples  of  maintenance  in¬ 
formation  exchange,  asset  management  data  exchange  at  several  U.S.  De¬ 
partment  of  Defense  agencies  are  described. 

Operations  and  Maintenance  System  Information  (OMSI) 

Information  exchange  between  construction  and  O&M,  in  the  public  sec¬ 
tor,  remains  awash  in  paper  submittals.  The  bright  spot  in  the  electronic 
information  exchange  is  the  capture  of  operations  data  at  the  end  of  the 
project  by  the  Naval  Facilities  Engineering  Command  (NAVFAC).  UFGS 
01781,  “Operations  and  Maintenance  Support  Information  (OMSI),”  re¬ 
quires  that  contractors  provide  a  complete  electronic  record  of  materials, 
products,  equipment,  and  systems.  OMSI  focuses  on  a  “first-generation” 
information  exchange  standard  that  simply  captures  the  electronic  equiva¬ 
lent  of  paper  (e-paper)  in  the  form  of  a  PDF  file. 

Various  studies  of  the  OMSI  requirements  have  attempted  to  identify  the 
characteristics  of  the  documents  captured  in  OMSI  [UFGS  01-78-23].  In¬ 
vestigation  of  the  metadata  associated  with  the  documents,  unfortunately, 
does  not  allow  an  understanding  of  the  information  contained  in  the  speci¬ 
fication.  Additional  studies  have  attempted  to  structure  preventive  main¬ 
tenance  activities  to  support  the  automated  import  of  schedules  into 
CMMS  [AEC3  2002].  While  helpful,  these  studies  have  not  addressed  the 
basic  question  of  what  is  exactly  required  in  the  OMSI  specification,  and 
how  may  it  be  captured  in  computable,  i.e.,  not  e-paper,  formats. 

This  following  paragraphs  and  associated  tables  extract  OMSI  data  to 
document  the  type  of  information  that  is  actually  required  within  the  PDE 
documents.  There  are  two  types  of  OMSI  tabular  information.  The  first  al¬ 
lows  defines,  from  the  point  of  view  of  OMSI,  a  spatial  plan  of  the  facility. 
The  second  type  of  tabular  information  identifies  key  equipment  located 
within  those  spaces. 

In  evaluating  the  information  provided  by  OMSI  for  its  applicability  to 
COBIE  it  is  important  to  evaluate  what  OMSI  information  was  directly 
created  during  the  construction  phase.  While  it  the  entire  set  of  OMSI  in¬ 
formation  may  be  useful,  it  may  not  be  cost-effective  to  require  construc¬ 
tion  contractors  to  provide  information  that  should  be  provided  by  infor¬ 
mation  exchange  by  designers,  in  advance  of  the  construction  contract. 
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OMSI  room  attributes 

To  allow  facility  managers  capture  data  about  the  general  characteristics  of 
the  facility  at  the  end  of  construction,  OMSI  requires  contractors  to  iden¬ 
tify  a  number  of  attributes  about  each  floor  and  the  spaces  within  these 
floors.  Table  2-44  -  Table  2-51  list  the  room  property  sets  currently  re¬ 
quired  by  OMSI. 


Table  2-44.  OMSI  general  room  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Room  Description 

Text 

50 

Room  Fioor  Area 

Number 

Double 

Table  2-45.  OMSI  room  celling  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

CeilingType 

Text 

50 

Ceiling  Area 

Number 

Double 

Table  2-46.  OMSI  room  door  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Door  Type 

Text 

50 

Door  Count 

Number 

Double 

Door  Facing  Direction 

Text 

50 

Table  2-47.  OMSI  room  floor  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Floor  Type 

Text 

50 

Floor  Color 

Text 

50 

Table  2-48.  OMSI  room  lighting  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Fixture  Type 

Text 

50 

Lighting  Fixture  Count 

Number 

Double 

Lighting  Fixture  Lamp  Count 

Number 

Double 

Watts  per  Lamp 

Number 

Double 
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Table  2-49.  OMSI  room  plumbing  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Plumbing  Fixture  Type 

Text 

50 

Plumbing  Fixture  Count 

Number 

Double 

Table  2-50.  OMSI  room  valve  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Valve  Type 

Text 

50 

Valve  System 

Number 

Double 

Valve  Normal  Position 

Text 

50 

Valve  Tag  Number 

Text 

50 

Valve  Location  Description 

Memo 

- 

Table  2-51.  OMSI  room  window  attributes. 


Field  Name 

Data  Type 

Size 

Room  Number 

Text 

50 

Window  Type 

Text 

50 

Windows  Count 

Number 

Double 

Window  Facing  Direction 

Text 

50 

OMSI  equipment  attributes 

In  addition  to  a  facilities  spatial  attributes,  OMSI  requires  information  be 
provided  related  to  equipment  assets  located  within  the  spatial  model.  Ad¬ 
ditional  data  about  these  assets  is  also  needed  to  operate  and  maintain  this 
equipment.  The  tabular  data  required  by  OMSI  is  identified  in  Table  2-52 
-  Table  2-55. 


Table  2-52.  OMSI  general  equipment  attributes. 


Field  Name 

Data  Type 

Size 

Equipment  Type 

Text 

50 

Equipment  Serial  Number 

Text 

50 

Equipment  Location 

Text 

50 

Equipment  Accepted  On 

Date 

- 
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Table  2-53.  OMSI  equipment  maintenance  attributes. 


Field  Name 

Data  Type 

Size 

Equipment  ID 

Text 

50 

PM  Instruction  Fiie 

Text 

50 

PM  Frequency 

Text 

50 

Table  2-54.  OMSI  equipment  part,  fuel,  lubricant  attributes. 


Field  Name 

Data  Type 

Size 

Part  for  Equipment  ID 

Text 

50 

Part  of  System  ID 

Text 

50 

Part  Description 

Text 

50 

Part  Number 

Text 

50 

Part  Manufacturer 

Com  pi  ex 

- 

Table  2-55.  OMSI  equipment  training  attributes. 


Field  Name 

Data  Type 

Size 

Training  for  Equipment  ID 

Text 

50 

Training  of  System  ID 

Text 

50 

Training  Description 

Text 

50 

Training  Source 

Text 

50 

Training  Provider 

Compiex 

- 

Cost  of  OMSI 

OMSI  data  is  gathered  at  the  conclusion  of  the  construction  project.  Paper 
documents  submitted  during  the  construction  and  commissioning  process 
are  compiled  or  scanned,  verified,  and  scanned  into  PDF  files.  Interviews 
with  the  NAVFAC  OMSI  office  indicate  that  the  average  cost  of  gathering 
the  OMSI  for  a  typical  NAVFAC  project  is  $4oK.  A  study  completed  for  the 
Architect  of  the  Capitol  concluded  that  the  cost  for  “data  commissioning” 
of  capital  projects  would  range  from  $5oKto  $iooK  [AOC  2005]. 

Fort  Lewis  Department  of  Public  Works 

The  Department  of  Public  Works  (DPW)  office  at  Fort  Lewis,  WA,  has  re¬ 
cently  begun  the  use  of  a  self-developed  format  for  the  identification  of 
equipment  and  preventative  maintenance  requirements.  The  content  of 
the  format,  specified  in  their  Section  1701  Specification  “Operations  and 
Maintenance  Manuals,”  includes  paper  documents  that  cover  the  following 
types  of  information  required  for  each  building  system: 
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•  system  description 

•  installed  equipment  lists 

•  start-up  procedures 

•  shutdown  procedures 

•  preventative  maintenance  requirements  and  schedule 

•  layout  diagrams 

•  control  devices  and  schematics 

•  maintenance  procedures 

•  troubleshooting  procedures 

•  non-standard  tools/equipment 

•  spare  parts  and  suppliers 

•  warranties 

•  product  data  sheets 

•  hazards  and  training  requirements. 

At  the  Fort  Lewis  DPW,  the  operations  and  maintenance  manuals  that 
contain  the  information  above  are  required  to  be  provided  in  PDF  format. 
In  addition  spreadsheets  are  required  for  the  following  information: 


Table  2-56.  DPW  equipment  locations. 


Table  2-57.  DWP  additional  equipment  fields. 

Device  Name 


Equipment  Number 
Description 
Serial  Number 


Model  Number 


Manufacturer 


Table  2-58.  Work  order  fields. 


Device  Name 


Task  Description 
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Schedule  Start  Date 
Status 


One  of  the  main  concerns  voiced  during  a  site  visit  to  the  DPW  was  a  li¬ 
brary  that  was  created  to  handle  the  large  number  of  documents  for  all  the 
facilities  at  Fort  Lewis.  The  library  configuration,  as  opposed  to  a  ware¬ 
house  of  banker  boxes  that  exists  at  other  installations,  was  identified  as  a 
very  effective  way  to  use  the  operations  and  maintenance  information  pro¬ 
vided  during  construction.  A  primary  concern,  as  the  library  grows,  is  the 
amount  of  space  required  to  house  these  documents.  Over  time  DPW  rep¬ 
resentatives  felt  that  they  would  prefer  to  have  everything  available  on-line 
versus  having  paper  copies. 

Handover  documentation 

For  U.S.  Department  of  Defense  projects  the  handover  of  information 
from  construction  to  operations  is  accomplished  using  the  Department  of 
Defense  (DD)  Form  1354,  Transfer  and  Acceptance  of  Military  Real 
Property.  The  form  contains  basic  asset  information  on  any  items  consid¬ 
ered  to  be  “real  property”  and  “personal  property.”  Real  property  assets 
are  those  building  components  that  are  a  fixed  part  of  the  project.  Personal 
property  assets  are  building  products  and  equipment  that  may  be  moved. 
The  designation  of  this  handover  information,  even  calling  it  by  the  name 
“property,”  correctly  communicates  the  “real  estate”  point  of  view  of  asset 
managers  in  the  Department  of  Defense. 

Another  aspect  of  handover  documentation  that  is  present  in  some  com¬ 
mercial  projects,  but  not  included  in  the  federal  projects  identified  in  this 
report  is  the  distinction  between  operations,  maintenance,  and  asset  in¬ 
formation.  In  process  plant  projects,  for  example,  the  operations  of  the  in¬ 
stalled  facility  provides  a  completely  different  set  of  instructions  from  the 
instructions  required  to  maintain  the  facility.  On  many  industrial  applica¬ 
tions  the  operators,  i.e.,  the  users  of  the  facility,  are  in  completely  different 
organizational  structures  from  those  who  ensure  proper  facility  mainte¬ 
nance. 

Handover  documentation  required  at  two  different  Department  of  Defense 
installations  is  provided  in  the  next  section.  Following  these  examples 
there  is  a  sub-section  with  conclusions. 
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Fort  Eustis,  VA  requirements 

Several  electronic  versions  of  the  DD  1354  are  available  one  of  these  ver¬ 
sions  documents  the  requirements  for  the  Director  of  Public  Works  at  Fort 
Eustis,  VA  [USA  2005].  Table  2-59  -  Table  2-62  identify  the  asset  data  re¬ 
quired  by  the  Department  of  the  Army  at  Fort  Eustis. 

Table  2-59.  DPW  project  header  data. 

Item  Required 

Building  Number 
Work  Order  Number 
Contract  Number 
Task  Order  Number 
Contract  Completion  Date 
Contract  Cost 
Project  Point  of  Contact 


Table  2-60.  DPW  project  description. 


Item  Required 

Size 

Bldg  Dimensions 

Main  Bldg 

Offsets 

Wings 

No.of  Usable  Floors 

Ceiling  Height 

Door  Height 

Door  Width 
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Table  2-61.  DPW  project  overview  data. 


Cat  Code 

Item  Required 

Size 

Unit 

Cost 

Building  +  5'  around 

SF 

81242 

Electrical  Distribution  (Underground) 

LF 

81241 

Electrical  Distribution  (Overhead) 

LF 

81230 

Exterior  Lighting 

LF 

81360 

Electrical  Transformers 

KV 

13510 

Communication  Lines 

LF 

82410 

Gas  Line 

LF 

83210 

Sanitary  Sewer  Line 

LF 

87110 

Storm  Sewer  Line 

LF 

84210 

Water  Lines  Potable 

LF 

84510 

Water  Lines  Non-potable 

LF 

84330 

Fire  Prot  Line  NP 

LF 

89240 

Fire  Hydrants 

EA 

85220 

Sidewalk 

SY 

85110 

Roads,  Paved 

SY-MI 

85130 

Roads,  Unpaved 

SY-MI 

85210 

Parking,  Organization 

SY 

85215 

Parking,  General 

SY 

85211 

Parking,  Unpaved 

SY 

87210 

Fence 

LF 

Storage  Tanks  (Underground) 

GA 

Storage  Tanks  (Above  Ground) 

GA 

83180 

Storage  Tanks  w/  Oil/Grease  Separator 

KG 
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Table  2-62.  DPW  project  components. 


Building  Component 

Type 

Type 

Type 

Foundation 

piers 

continuous  footers 

Foundation  materiais 

concrete 

reinforced  concrete 

Sub  floor 

cone  slab 

wood 

Fioor  surface 

vinyl  tile 

concrete 

Exterior  waiis 

brick 

vinyl  siding 

Interior  waiis 

dry  wall 

insulated  panel 

Roof  support: 

fiat  truss 

arch  truss 
joist  or  beam 
roof  deck 

roof  surface 

wood 

reinforced  concrete 

wood 

reinforced  concrete 

wood 

steel 

slab 

wood 

metal 

steel 

shingles 

steel 

Utility  connections 

Number 

Size 

water 

sanitary  sewer 

storm  sewer 

eiectricity 

gas 

steam 

condensate 

steel 

steel 

concrete 

rubber 

Air  conditioning 

Number 

Size 

type: 

capacity  (tons): 
modei: 

seriai: 

Fire  protection 

Number 

Size 

type  (pull/sprinkler): 
number: 

conn  to  fire  station?: 

Heating 

source: 

fuel: 

no.  of  MBTUs: 

model: 

serial  number: 

furnace 

unit  heater 

elec 

gas 

Domestic  hot  water  facilities 

capacity  (gal): 
temperature  rise: 
type 

gas 

electric 

oil 
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U.S.  Air  Force  Academy  requirements 

In  addition  to  the  Army,  other  services  have  developed  their  own  versions 
of  DD  Form  1354  (Table  2-63).  The  example  shown  in  Table  2-64  -  Table 
2-74  refers  to  a  document  produced  by  the  U.S.  Air  Force  Academy  Design 
and  Construction  office  [USAF  1999]. 


Table  2-63.  USAF  general  project  description. 


ESTIMATED  PROJECT  COST 

$ 

ACTUAL  CONSTRUCTION  COST 

$ 

TOTAL  FLOOR  SPACE  new  building 

SF 

TOTAL  FLOOR  SPACE  addition 

SF 

TOTAL  FLOOR  SPACE  rehab  existing 

SF 

NUMBER  OF  FLOORS 

NO 

Material  Types  (list  predominant  type) 

foundation 

wall 

roof 

flooring 

Utilities  Entering  Building 

size 

water 

sewer 

gas 

electricity 

telephone 

fiber 
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Table  2-64.  USAF  fire  protection  system. 


Category 

Fire  Protection 

QUAN 

UNIT 

COST 

880-211 

closed  head  auto  sprinklers 

/ 

SF/HD 

880-212 

open  head  auto  sprinkler 

/ 

SF/HD 

880-216 

preaction  sprinkler  system 

/ 

SF/HD 

880-217 

afff  preaction  sprinkler  sys¬ 
tem 

/ 

SF/HD 

880-218 

high  expansion  foam 

EA 

880-221 

auto  fire  detection  system 

/ 

SF/HD 

880-222 

manual  fire  alarm  system 

EA 

880-231 

carbon  dioxide  fire  system 

EA 

880-232 

foam  fire  systems 

EA 

880-233 

other  fire  system 

EA 

880-234 

halon  fire  system 

EA 

880-235 

dry  chemical  system 

EA 

Table  2-65.  USAF  security  system. 


Category 

Security 

QUAN 

UNIT 

COST 

872-841 

security  alarm  system 

EA 

Table  2-66.  USAF  mechanical/electrical  system. 


Category 

Mechanical/Electrical 

QUAN 

UNIT 

COST 

890-126 

a/c  units 

TN 

890-125 

a/c  units  <5TN 

TN 

890-121 

a/c  unit  5-25TN 

TN 

Air  Handling  Unit 

Evap  Cooling 

823-111 

Heat  Pumps 

821-115 

HTHW  converter 

MB 

821-116 

MTHW  converter 

MB 

821-155 

Individual  boiler  plant 

MB 

Transformer 

KVA 

890-180 

Utility  Meters 

EA 

890-134 

air  compressor 

HP 

890-144 

compressed  air  dist  system 

EA 

811-147 

emer  power  generator 

KW 

emer  lighting 

EA 
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Table  2-67.  USAF  Miscellaneous  Systems. 


Category 

Misc 

QUAN 

UNIT 

COST 

Elevators 

EA 

Hoist 

EA 

890-158 

Loading  Dock 

SF 

Appiiances 

EA 

Rear  Projection  Screens 

EA 

Postai  Lock  Boxes 

EA 

Attached  Seating 

EA 

Sateiiite  Antennas 

EA 

Lockers(permanent) 

EA 

890-161 

Misc  Support  Structure 

EA 

Table  2-68.  USAF  electrical  utilities. 


Category 

Electric  Distribution 

QUAN 

UNIT 

COST 

812-223 

Primary  Distro  Line  Overhead 

LF 

812-224 

Secondary  Distro  Line  Ovhd 

LF 

812-225 

Underground  Prim  Distr  Line 

LF 

812-226 

UG  Secondary  Prim  Dist  Line 

LF 

Category 

Substations  and  Switching  Stations 

813-228 

Eiect  Switching  Station 

EA 

813-231 

Eiect  Substation 

KW 

Category 

Elec  Use  Facilities 

812-926 

Exterior  Area  Lighted 

EA 

812-928 

Traffic  Lights 

EA 

Table  2-69.  Heating  and  cooling  systems. 


Category 

Heat,  Gas  -  Transmission 

QUAN 

UNIT 

COST 

821-115 

Heat  plant  750-3500  MB 

MB 

821-116 

Heat  plant  over  3500  MB 

MB 

823-244 

Gas  Storage 

CF 

824-464 

Gas  Mains  (list  sizes) 

LF 

824-468 

Gas  Valve  Facility 

SF 

Category 

Air  Conditioning 

826-122 

Air  Conditioning  25-100  tons 

TN 

826-123 

Air  Conditioning  >100  tons 

TN 
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Table  2-70.  Water  and  wastewater  utilities. 


Category 

Wastewater 

QUAN 

UNIT 

COST 

831-165 

Sewage  Treatment  Systems 

KG 

831-168 

Wastewater  Treatment  Bldg 

SF 

831-169 

Sewage  Septic  Tank 

KG 

832-266 

Sanitary  Sewer  Main  (iist  sizes) 

LF 

832-267 

Sanitary  Sewage  Pump  Station 

SF 

Category 

Water  Supply  and  Storage 

QUAN 

UNIT 

COST 

841-161 

Water  Supply  Main 

841-165 

Water  Supply  Treatment 

KG 

841-166 

Water  Well 

KG 

841-169 

Water  Supply  Building 

SF 

841-425 

Water  Storage  Reservoir 

KG 

841-427 

Water  Tank  Storage 

KG 

842-245 

Water  Distro  Mains  (list  all 
sizes) 

LF 

842-246 

Water  Hydrants 

EA 

842-249 

Water  Pumping  Stations 

SF 

843-314 

FP  Distribution  Mains 

LF 

843-315 

Fire  Hydrants 

EA 

843-319 

FP  Water  Storage 

KG 

844-367 

Non-Pot  Water  Storage 

KG 

844-368 

Non-Pot  Water  Supply  System 

EA 

845-362 

Non-Pot  Supply  Bldg 

SF 

845-363 

Non-Pot  Water  Mains 

LF 

Table  2-71.  USAF  pavement  systems. 


Category 

Roads 

QUAN 

UNIT 

COST 

851-142 

Bridges 

LF 

851-143 

Curb  and  Gutter 

LF 

851-145 

Driveways 

SY 

851-147 

Roads 

SY 

852-261 

Parking,  org 

SY 

852-262 

Parking,  non-org 

SY 

852-289 

Sidewalk 

SY 

852-287 

Pedestrian  Bridge 

LF 

Category 

AIRFIELD 

QUAN 

UNIT 

COST 

113-321 

Aprons 

SY 

111-111 

Runway 

SY 

112-211 

Taxi  ways 

SY 
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Table  2-72.  USAF  drainage  system. 


Category 

QUAN 

UNIT 

COST 

871-183 

Storm  Drainage  (list 
sizes, feature) 

LF/ea 

pipe 

channel 

catch  basin 

culvert 

manhole 

inlet 

871-185 

Storm  Drainage  Pump  Station 

SF 

Table  2-73.  USAF  miscellaneous  utilities. 


Category 

QUAN 

UNIT 

COST 

871-187 

Retaining  Wall 

SF/LF 

872-245 

Fence,  Boundary 

872-247 

Fence,  Security 

LF 

890-181 

Utility  Line  Conduit/Duct 

890-185 

Utility  Tunnel 

890-187 

Ultility  Vault 

LF 

Utility  Manhole 

LF 

Comm  Manhole 

EA 

135-183 

Duct 

LF 

135-586 

Telephone 

LF 

890-171 

Misc  Fuel  Storage  Tank 

KG 

890-269 

Cathodic  Protection  Systems 

EA 

Oil  Water  Separater 

EA 

HTHW  Lines  (list  sizes) 

LF 

MTHW  Lines 

LF 

841-161 

Irrigation  Sprinkler  System 

HDS 

Table  2-74.  EMCS. 


Category 

QUAN 

UNIT 

COST 

890-271 

EMCS  Central  Station 

EA 

890-272 

EMCS  Field  Equipment 

EA 

890-273 

EMCS  Data  Links 

EA 

In  addition  to  the  “real  property”  that  is  installed  with  the  construction  or 
renovation  project  there  are  also  many  property  items  that  are  considered 
assets,  at  least  in  referenced  USAF  document,  that  are  not  permanently 
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installed  in  the  facility.  The  items  that  fall  into  that  category  are  identified 
in  Table  2-75. 


Table  2-75.  USAF  semi-permanent  assets. 


Item 

QUAN 

UNIT 

COST 

Appliances  (list  each) 

EA 

Air  Dryers/Compressors 

EA 

Auditorium  Curtains 

SF 

Central  Vac  Sys 

EA 

Chalkboards 

SF 

Chapel  Equip 

pews 

LF 

altars 

EA 

pulpits 

EA 

baptistry 

EA 

Chlorinators 

EA 

Dehumidifiers 

EA 

Electronic  Air  Cleaner 

EA 

Fire  Shutters 

EA 

Room  divider  curtain 

EA 

Latrine  Equipment 

lavatories 

EA 

commodes 

EA 

urinals 

EA 

Playground  Equip  (list) 

EA 

Projection  screens 

EA 

Saunas 

EA 

Scoreboards 

EA 

Spray  Paint  Booth 

EA 

Stadium  Seats 

EA 

Theater  Chairs 

EA 

Wardrobes/Lockers 

EA 

Window  A/C  unit 

EA 

Discussion 

The  current  requirements  to  document  “real”  and  “personal”  property 
each  have  their  own  implications  for  the  COBIE  project.  When  considering 
the  “real”  property  estimates  of  space  for  individual  functions  should  be 
specified  in  a  consistent  method.  There  are  many  different  methods  for 


ERDC/CERLTR-07-30 


47 


calculating  the  size  of  spaces  today.  For  example  the  space  boundaries  may 
be  based  on  the  usable  space,  centerlines  of  walls  or  full  dimensions  in¬ 
cluding  walls.  Vertical  distances  may  limit  to  the  ceiling,  bottom  of  the 
structure,  or  to  the  bottom  of  the  floor  above. 

Today  there  are  competing  standards  that  define  the  rules  for  calculating 
space  areas  and  volumes  [Tracy  2003].  American  Society  of  Testing  and 
Materials  (ASTM)  standard  E  1836-01  provides  definitions  for  the  meas¬ 
urement  of  floor  areas  for  “facility  management,  occupant  requirements, 
space  planning,  or  strategic  facility  planning.”  This  ASTM  standard  was 
initially  developed  by  the  International  Facility  Managers  Association 
(IFMA)  “Standard  Classification  for  Building  Area  Measurements.”  The 
Building  Owners  and  Managers  Association  (BOMA)  standard,  approved 
by  ANSI,  Z65.1-1996,  specifies  the  measurement  of  industrial  and  retail 
facilities. 

Anecdotal  evidence  from  the  importation  of  test  IFC  models  has  demon¬ 
strated  that  the  resulting  floor  area  calculations  are  different  when  created 
by  different  CADD  software  vendors.  Until  efforts  to  harmonize  the  IFMA 
and  BOMA  standards  for  real  property  have  been  completed,  COBIE 
should  not  include  such  requirements  in  a  given  specification.  If  provided, 
use  of  different  standards  could  provide  different  information  to  asset 
managers. 

Regarding  personal  property,  there  appears  to  be  little  dispute  about  the 
data  exchanged  or  required.  The  personal  property  handover  data  re¬ 
quired  are  (1)  the  name  of  the  item,  (2)  that  number  of  items  in  the  build¬ 
ing,  and  (3)  the  per  unit  cost.  While  the  name  of  items  and  count  could  be 
identified  from  the  data  identified  in  COBIE,  the  provision  of  cost  infor¬ 
mation  by  the  contractor  may  not  be  available.  It  is  not  clear,  however, 
from  the  information  provided  if  the  cost  figure  required  in  a  previous  ta¬ 
ble  is  first-cost  or  replacement-cost.  In  addition,  it  is  not  clear  that  per¬ 
sonal  inventory  is  required  to  be  located  within  the  facility.  This  is  in  con¬ 
trast  to  real  property  that  is  identified  within  a  specific  room  based  on  the 
OMSI  specification. 

Electronic  submittal  processing  at  NASA 

This  section  reviews  the  organization  and  contents  of  electronic  construc¬ 
tion  files  related  to  NNS05AA76C  with  Trans-Gulf  Constructors.  Contract 
NNS05AA76C  installed  underground  storage  tanks  and  piping  at  one  of 
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the  propulsion  test  complex  areas  at  the  Stennis  Space  Center.  These  files 
and  files  for  Contract  NAS13  01049  were  provided  by  Ms.  Michelle  Craft, 
Project  Manager,  Stennis  Space  Center. 

NNS05AA76C project  files 

NNS05AA76C  contract  files  were  provided  in  folders  organized  by  media 
type,  e.g.,  “Emails,”  as  well  as  functional  type,  e.g.,  “Transmittals.”  While 
not  fully  evaluated,  it  is  interesting  to  note  that  the  organization  of  the  files 
provided  on  another  contract,  NAS1301049,  were  organized  in  a  different 
set  of  folders.  The  use  of  standard  contract  folder  naming  conventions,  or¬ 
ganized  by  business  processes,  commonly  found  at  NAVE  AC  ROICC  and 
USACE  Area  Offices  were  not  reflected  in  the  organization  of  the  electronic 
data. 

Within  different  folders,  files  could  be  identified  that  referenced  the  same 
subject.  Eor  example  under  the  "Emails"  folder  a  files  called  "Xmtl  042 
John  Haynes.rtf'  and  “Xmtl  042  LDQ.rdf’  also  pertain  to  the  "Transmit¬ 
tal"  folder  file  “Xmtl  042.pdf’  and  the  "Letters"  folder  file  “05-0220SMO 
Xmtls  038,  042,  043B.DOC”.  Eiles  pertaining  to  the  same  “Request  for  In¬ 
formation”  and  “Eield  Change  Requests”  topic  could  also  be  found  in  dif¬ 
ferent  folders. 

Many  files  contained  correspondence  related  to  multiple  topics.  Eor  exam¬ 
ple,  the  file  name  “05-0220SMO  Xmtls  038,  042,  043B.DOC”  clearly  per¬ 
tains  to  submittal  package  038,  042,  and  a  supplemental  submission  of 
transmittal  043B.  Tracing  the  thread  of  each  discussion  and  identifying 
the  overall  status  of  submittal  required  the  production  and  maintenance  of 
summary  files  such  as  that  found  in  “Transmittal  Listing  for  All.xls.”  On 
the  other  project,  NAS1301049,  summary  data  was  maintained  in  a  Micro¬ 
soft  Access  database,  “Xmtl  Info  NAS1301049.mdb”. 

A  view  of  the  entire  set  of  files  after  the  completion  of  construction  some¬ 
what  masks  the  time  sequence  of  the  information.  One  issue  of  importance 
is  that  different  files  pertaining  to  the  same  topic  as  part  of  the  same  proc¬ 
ess,  such  as  submittal  review  requires.  Eor  example  the  files  called  "Xmtl 
036A  John  Haynes.rtf  and  “Xmtl  036A  LDQ.rdf  both  pertain  to  submit¬ 
tal  036A.  These  files  also  contain  different  responses  to  the  referenced 
submittal.  The  dates  noted  in  the  emails  captured  by  these  files  are  20-Jul- 
05  and  i8-Ju1-05,  respectively.  These  dates  demonstrate  good  coordina- 
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tion  between  the  reviewers  and  prompt  review  of  contractor  submitted 
data. 

Electronic  submittal  files  provided  by  the  contractor  appear  to  have  been 
distributed  by  the  “configuration  coordinator”  who  collected  the  re¬ 
sponses.  It  could  be  expected  that  from  time  to  time  this  coordinator 
would  have  been  required  to  adjudicate  differences  of  opinion  on  submit¬ 
tals,  and  other  matters,  as  well  as  ensure  that  reviews,  and  other  job  func¬ 
tions,  were  completed  within  the  required  time  frame. 

The  need  for  distribution  of  submittal  reviews  among  personnel  from  dif¬ 
ferent  offices  or  between  facility  operator  and  designers  could  not  be  es¬ 
tablished  from  the  data  provided.  This  is  because  the  office  names  of  users 
email  addresses  were  stripped  out  when  the  email  was  saved.  It  would  be 
expected,  however,  that  some  larger  projects  utilize  resources  outside  the 
office  of  the  configuration  coordinator  and/or  project  manager. 

Responses  regarding  the  status  of  individual  submittals,  RFIs,  etc.,  were 
found  in  the  “Letters”  folder.  With  the  exception  of  “boilerplate”  informa¬ 
tion  about  the  project,  a  “disclaimer”  statement,  and  Contracting  Officer’s 
Technical  Representative  identification  the  submittal  information  re¬ 
turned  to  the  contractor  appeared  to  be  directly  compiled  from  the  infor¬ 
mation  provided  by  submittal  reviewers.  The  timeliness  of  these  responses 
was  very  good  in  the  examples  specifically  reviewed  by  the  author.  For  ex¬ 
ample,  the  letter  response  for  transmittal  036A,  “05-0217SMO  Xmtl 
036A.DOC”,  was  signed  on  22-JUI-05,  four  calendar  days  following  the  last 
review  comment  submission. 

While  RFIs  and  Field  Change  Requests  (FCRs)  are  submitted  on  an  ad-hoc 
basis,  submittals  are  provided  against  a  required  schedule,  or  “register,”  of 
submittals.  This  register  is  a  catalog  of  the  materials,  components,  equip¬ 
ment  and  systems  to  be  installed  on  the  project.  The  register  also  catalogs 
informational  requirements  that  allow  quality  control  and  follow-on  O&M 
activities  to  be  conducted.  In  the  sample  project  reviewed  there  was  a  sig¬ 
nificant  mismatch  between  the  submittal  register  generated  for  the  project 
and  the  actual  submittals  received  from  the  contractor.  There  were  several 
possible  reasons  for  this  mismatch  that  could  be  surmised  by  examining 
specific  submittal  file  contents. 
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In  many  cases,  submittals  contained  multiple  sets  of  individual  transmittal 
documents,  from  different  sources,  that  could  have  been  separated  into 
individual  submittal  documents  pertaining  to  more  than  one  section  of  the 
register.  For  example,  submittal  009,  related  to  cast  in  place  concrete 
pads,  contained  16  individual  submittals  including  catalog  cuts,  mix  de¬ 
sign,  test  reports  of  various  kinds,  and  delivery  tickets.  Other  submittals 
identified  in  the  submittal  register  for  cast-in-place  concrete  (and  associ¬ 
ated)  specification  sections  were  not  found,  by  this  author,  for  example  re¬ 
bar  delivery  tickets  or  steel  test  results. 

It  is  interesting  to  note  that  transmittals  contained  information  about 
work  accomplished  in  specific  areas  of  the  project.  For  example,  the  mix 
design  and  aggregate  test  data  could  for  a  specific  batch  of  concrete  could 
have  been  correlated  with  the  compressive  strength  test  results  for  con¬ 
crete  placed  in  a  specific  location  on  the  project.  Such  an  observation 
could,  no  doubt,  also  be  made  on  documents  related  to  mix  design,  deliv¬ 
ery  tickets,  and  cylinder  test  results  on  most  projects  regardless  of  agency 
overseeing  the  construction. 

Noticeably  absent  from  the  data  disk  were  daily  reports  and  progress  pho¬ 
tos.  Given  the  focus  on  information  exchange  related  to  Operations  and 
Maintenance  issues,  such  information  may  simply  have  not  been  provided 
by  the  Center. 

Opportunities  to  streamiine  existing  process 

Consistent  organization  of  electronic  files  would  greatly  improve  ability  to 
find  relevant  documents.  A  standard  organization  for  construction  file 
folders  was  not  found  using  a  Google  search  at  “site:  nasa.gov.”  If  the  or¬ 
ganization  were  based  on  specific  type  of  business  activity,  e.g.,  “submit¬ 
tal”  or  “rfi”,  then  tracking  issues  from  inception  through  conclusion  would 
be  more  easily  accomplished.  While  this  would  be  a  good  start,  for  file- 
based  project  archives  a  desktop  or  network  search  engine  would  also  be 
needed  to  identify  similar  content  from  multiple  files.  One  such  free  tool 
that  does  not  post  data  on  outside  servers  is  called  Copernic 
(http://www.copernic.com/). 

A  key  requirement  for  all  file-based  document  organization  schemes  is 
that  documents  must  pertain  to  a  single  subject  only. 
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Once  organized,  distribution  of  files  over  the  web  would  create  a  document 
repository  without  requiring  the  re-transmission  of  documents  by  email 
attachments.  Depending  on  the  nature  of  the  repository,  information 
about  specific  projects  could  be  limited  to  those  contractors  or  others  who 
have  a  concern  regarding  the  privacy  of  contractor  pricing  or  other  pro¬ 
prietary  data.  This  repository  could  also  be  used  by  the  contractor  to  pro¬ 
vide  their  transmittal,  in  lieu  of  paper  copies. 

Provision  of  a  web-based  file  exchange  should  be  designed  to  allow  suppli¬ 
ers  and  manufacturers  to  directly  provide  PDF  files  of  materials  and 
equipment  to  be  purchased.  Such  PDF  cut  sheets  are  widely  available  as  a 
Google  search  of  most  product  titles  will  show.  Allowing  the  supplier  or 
manufacture  to  provide  this  information  directly  will  eliminate  the  cost  of 
scanning  documents  by  owner  or  contractor. 

A  standard  tool  to  track  the  status  of  individual  transmittals  and  overall 
submittals  would  be  helpful  since  the  cost  to  create,  maintain,  and  share 
individual  tools  to  track  transmittal  status  could  be  eliminated.  The  con¬ 
tent  of  the  submittal  register  should  be  based  on  the  submittal  require¬ 
ments  identified  by  the  designer  and  not  the  submittals  provided  by  the 
contractor.  The  decomposition  of  large  contractor  submittals  into  individ¬ 
ual  transmittals  will  also  demonstrate  better  compliance  by  the  contractor 
with  the  designer-specified  submittal  requirements.  Smaller  files  will  also 
allow  the  owner’s  representative  to  more  easily  verify  the  contents  and 
resolution  of  each  transmittal.  Having  a  shared,  standard  tool  would  fur¬ 
ther  improve  productivity  since  the  status  of  issues  would  be  known  to  all 
project  stakeholders. 

Even  if  contractor  submittals  were  decomposed  into  their  elemental  parts 
and  provided  as  separate  transmittals,  these  documents  typically  apply  in 
multiple  locations  within  a  submittal  register.  For  example  transmittal 
008  contains  “Installation  Instructions”  for  the  underground  storage  tank. 
These  instructions  should  be  linked  both  to  the  submittal  for  O&M  data 
and  the  original  product  submittal.  Unfortunately  within  the  context  of 
standard  file  exchange  programs  such  a  linkage  could  not  be  supported. 

The  cross  referencing  of  information  within  documents  to  the  geometry 
and  components  within  the  facility  requires  a  Building  Information  Mod¬ 
eling  (BIM)  approach.  COBIE  allow  information  to  be  linked  to  all  its  as¬ 
sociated  information.  This  “tagging”  is  done  by  the  group  who  initially  ere- 
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ates  the  data.  For  example,  the  geometric  layout  of  a  project  is  identified 
during  the  design  along  with  all  named  equipment,  and  the  location  for 
that  equipment.  The  contractor  provides  the  serial  number,  instructions, 
manuals,  etc.,  for  the  equipment  during  the  process  of  construction. 

COBIE  supports  this  life-cycle  project  information  exchange  with  the  re¬ 
sult  that  Computerized  Maintenance  Management  System  (CMMS)  data 
can  be  automatically  provided  at  the  end  of  construction. 

A  key  concern  of  facility  maintainers,  operators,  and  asset  managers  is  that 
the  data  currently  provided  at  the  end  of  construction  is  insufficient  for 
their  needs.  Unfortunately,  the  majority  of  information  needed  for  Com¬ 
puterized  Maintenance  Management  Systems,  Computerized  Facility 
Management  Systems,  and  property  inventory  systems  must  be  retyped 
from  paper  files  provided  at  construction  handover.  Use  of  the  example 
project  files  or  those  from  the  NAVFAC  OMSI  system  demonstrate  that 
even  the  capture  of  e-paper,  in  the  form  of  PDF  files  is  insufficient  to  meet 
the  needs  of  facility  maintainers,  operators,  and  managers. 

Asset  management 

While  there  are  differences  between  facility  management,  facility  opera¬ 
tions,  and  facility  maintenance  these  three  aspects  of  “asset  management” 
are,  in  the  building  industry,  almost  always  used  synonymously.  Overall 
facility  management  will  have  specific  requirements,  based  on  the  ac¬ 
counting  schemes  employed  by  the  parent  organization  to  allocate  opera¬ 
tional  mission  and  costs  to  individual  facilities  or  spaces.  Operations  man¬ 
agement  requires  information  about  the  how  to  use  the  facility  to 
accomplish  the  needed  production  work  within  the  space.  Maintenance 
management  is  the  process  of  keeping  the  facility  in  working  operational 
condition. 

A  study  of  information  needs  by  facility  managers  identified  the  need  for 
asset  inventories,  environmental  performance  requirements,  performance 
metrics,  and  maintenance  plans  [Hassanain  2003].  Hassanain’s  model 
identifies:  an  asset  as  either  an  individual  asset  or  a  part  of  a  group  of 
other  assets,  tasks  associated  with  the  asset,  products  or  collections  of 
products  that  comprise  the  asset,  and  tasks  associated  with  these  products. 

Systems  for  asset  management  require  initialization  through  the  entry  of 
information  regarding  the  design,  construction,  and  commissioning 
phases.  To  begin  operations  the  asset  management  system  accepts  data 
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from  “upstream”  in  the  process.  To  operate  the  facility  the  asset  manage¬ 
ment  system  must  also  accept  updates  to  equipment  condition  and  job 
status. 

If  an  automated  asset  management  system  were  in  place,  and  could  be 
provided  with  information  on  new  projects  as  well  as  the  status  of  ongoing 
operations  and  maintenance  activities,  then  the  system  should  be  able  to 
answer  six  “crucial”  questions.  [Vanier  2001].  These  questions  are  noted  in 
the  list  below: 

•  What  assets  do  you  own? 

•  What  is  the  value  of  these  assets? 

•  What  is  the  condition  of  these  assets? 

•  What  tasks  are  required  to  maintain  asset  serviceability? 

•  What  how  long  will  the  asset  effectively  operate? 

•  What  is  the  plan  for  maintenance  of  all  assets? 

Quality  control 

Given  the  state  of  practice  described  in  the  previous  sections  it  is  clear  that 
there  is  no  simple  current  standard  that  can  be  directly  applied  to  capture 
the  full  set  of  data  needed  for  asset  management.  While  it  is  possible  that 
the  creation  of  a  standard  could  pull  the  data  from  construction  contrac¬ 
tors  and  provide  it  to  facility  operators,  such  approaches,  e.g.,  OMSI,  have 
been  shown  to  be  expensive  and  require  additional  staff  to  execute.  An¬ 
other  way  to  frame  the  COBIE  standard  is  to  modify  currently  procedures, 
methods,  and  formats  for  current  data  exchange. 

To  ensure  that  the  COBIE  standard  is  widely  adopted,  COBIE  must  find 
operate  within  the  context  of  existing  business  processes.  Current  paper 
exchange  and  the  public  sector  OMSI  and  DPW  efforts  are,  primarily, 
based  on  an  existing  contract-driven  process  called  contractor  quality  con¬ 
trol  (CQC).  In  the  CQC  process  the  construction  contractor  is  responsible 
to  ensure  that  their  work  has  been  done  in  accordance  with  the  perform¬ 
ance  requirements  identified  in  the  contract  documents.  One  of  the  re¬ 
quirements  that  demonstrate  effective  CQC  is  the  submittal  that  demon¬ 
strates  compliance  of  materials,  products,  equipment,  and  systems  with 
requirements  contained  in  the  construction  contract. 

The  submittal  of  information  about  building  materials,  products,  equip¬ 
ment,  and  systems  is  a  “natural”  point  of  capture  of  COBIE  data  during 
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construction.  This  is  because  the  data  is  already  being  provided.  Changing 
the  format  of  the  information,  and  ensuring  that  a  standard  set  of  data  is 
being  submitted  based  on  the  specific  submittal  are  the  essential  aspects  of 
COBIE.  COBIE  will  help  clarify  the  set  of  information  being  evaluated  dur¬ 
ing  shop  drawing  approvals  and  submittal  reviews.  In  addition,  COBIE 
must  view  the  CQC  process  to  include  information  flows  as  well  as  paper 
submissions.  The  consideration  of  these  contractual  (and  collaborative) 
business  flows  will  be  critical  to  COBIE’s  long-term  success  [Arditi  and 
Gunaydin  1998]. 

While  there  are  several  processes  within  the  planning,  bidding,  design, 
and  construction  stages  that  allow  the  capture  of  facility  management  re¬ 
lated  information,  the  clearest  and  most  efficient  means  to  capture  infor¬ 
mation  for  ban  doff  between  construction  and  operations.  As  a  result,  the 
initial  COBIE  specification  will  focus  on  the  collaborative  and  contractual 
processes  needed  to  process  submittals.  The  paragraphs  below  describe 
the  submittal  review  portion  of  the  CQC  process  and  identify  specific  areas 
in  which  COBIE  information  could  be  captured. 

Submittal  of  manufactured  components 

In  public-sector  projects,  the  lead  designer  identifies  all  submittals  to  be 
provided  during  construction  [NGB  2003].  The  description  the  products 
and  materials  with  related  constraints  are  be  found  in  design  specifica¬ 
tions.  Specifications  that  cover  a  wide  range  of  projects,  such  as  UEGS,  are 
tailored  during  the  design  process  to  describe  only  those  products  and  ma¬ 
terials  included  in  a  specific  project.  Once  the  specifications  have  been 
completed,  a  list  of  the  products  and  materials  to  be  included  in  the  pro¬ 
ject  may  be  generated. 

During  construction  information  about  each  of  the  products  and  materials 
on  the  project-specific  list  are  used  to  select  materials,  equipment,  and 
products  meeting  the  designer’s  minimum  performance  requirements.  In¬ 
formation  about  building  systems  is  also  required  to  explain  how  compo¬ 
nents  are  to  be  integrated  in  systems,  operated,  and  maintained. 

The  private  industry’s  use  of  automated  information  exchanges  for  sub¬ 
mittal  review  is  based  on  the  electronic  transmission  of  paper  documents. 
Transmitting  these  documents  electronically  simply  decrease  the  time  re¬ 
quired  to  receive  documents,  it  does  nothing  to  improve  the  quality  of  the 
information  exchanged  [Bjork  2002].  The  difficulty  of  retrieving  the  cor- 


ERDC/CERLTR-07-30 


55 


rect  electronic  documents  is  increased  since  the  equivalent  of  standard  pa¬ 
per  file  folder  schemes,  required  for  the  storage  of  paper  documents,  are 
difficult  to  check  and  enforce  when  exchanging  electronic  documents. 
Document  taxonomies  and  search  engine  technology  can  assist,  provided 
all  required  documents  are  provided. 

Submittal  of  engineered  components 

While  manufactured  products,  once  selected  have  a  fixed  set  of  informa¬ 
tion  content  that  is  augmented  by  location  and  serial  number  during  in¬ 
stallation,  information  describing  engineered  items  becomes  more  refined 
through  the  construction  process.  For  example,  shop  drawings  go  through 
several  stages  completed  by  a  project-specific  (or  possibly  project-unique) 
set  of  manufacturers,  fabricators,  and  installers.  These  stages  include  (i) 
detailed  design,  (2)  fabrication  instructions,  (3)  assembly  instructions,  (4) 
erection  instructions,  and  (5)  installation  instructions  [Pietroforte  1997]. 
The  current  paper-based  coordination  processes  used  to  review  and  coor¬ 
dinate  the  production  of  engineered  items  are  prone  to  errors  resulting 
from  miscommunication  [Terry  1996]. 

Trades  often  need  to  work  together  to  coordinate  their  work  to  ensure  the 
specified  outcome.  For  example  in  precast  concrete  panels  the  precast 
manufacture,  glaziers,  and  erectors  must  work  together  to  ensure  panels 
restrict  moisture  transmission.  Operational  requirements  of  such  compo¬ 
nents  also  are  more  complex  than  that  of  most  manufactured  products. 
This  is  because  systems  with  different  materials  often  have  different  ther¬ 
mal  response  properties  and  require  different  types  of  maintenance  for 
each  of  the  types  of  material  in  the  system. 

Efforts  to  streamline  information  exchange  of  engineered  components 
have  significant  implications  legal  with  regard  to  the  expected  accuracy  of 
electronic  working  drawings.  Drawing  sets  without  consistent  accuracy  or 
with  needs  for  different  levels  of  accuracy  have  resulted  in  claims  when 
these  documents  are  directly  applied  outside  the  context  in  which  they 
were  created.  To  attempt  to  resolve  such  issues  national  trade  and  profes¬ 
sional  associations  have  been  developing  standards  for  the  legal  issues 
surrounding  the  exchange  of  electronic  documents.  The  American  Insti¬ 
tute  for  Steel  Construction  (AISC)  has,  for  example,  added  a  code  section 
governing  the  use  of  electronic  documents  for  shop  drawing  review  [Har¬ 
man  2000].  The  concern  is  often  cited  by  designers  and  consultants,  how¬ 
ever,  professionals  interviewed  by  this  author  have  also  identified  prob- 
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lems  associated  with  construction  contracting.  For  example,  reliance  on 
designer  produced  CADD  drawings  for  construction  bidding  have  resulted 
in  claims  by  construction  contractors  due  to  inconsistent  and  inaccurately 
scaled  CADD  diagrams  [Harman  2000]. 

While  the  increased  accuracy  (or  inaccuracy)  of  electronic  documents  has 
resulted  in  claims,  there  are  also  benefits  to  having  the  electronic  docu¬ 
ments  identified  by  the  author.  Audit  trails  have  been  used  by  the  author 
to  defend  against  multi-million  dollar  construction  claims  resulting  from 
issues  that  were  fully  resolved  during  the  bidding  process.  Team  members 
have  also  been  able  to  verify  who  has  received  the  latest  versions  of  docu¬ 
ments  to  ensure  proper  coordination  [Harman  2000]. 

Example  submittal  register 

If  the  2006  UFGS  were  applied  in  their  entirety  to  a  given  project,  there 
would  be  a  total  of  8,319  individual  submittals.  The  Specsintact  software, 
used  to  create  UFGS  for  individual  projects,  provides  a  proprietary  data 
exchange  format  using  a  comma-delimited  text  file  used  to  exchange  sub¬ 
mittal  tracking  information  [http :  /  /specsintact.ksc.  nasa.  gov/1 .  Table  2-76 
shows  the  position  of  each  field  (column  1),  the  description  of  the  contents 
of  the  field  (column  2),  and  the  party  responsible  to  provide  the  data  (col¬ 
umn  3).  The  file  format  contains  information  that  may  be  exchanged  dur¬ 
ing  the  construction  and  other  information  that  is  needed  at  the  start  of 
the  project. 

Designer  information  is  captured  in  fields  3,  4,  5,  and  6.  Contractor  sup¬ 
plies  information  in  several  phases.  First  the  contractor  provides  the  sub¬ 
mittal  schedule  through  fields  1,  7,  8,  and  9.  When  the  submittal  is  sent  to 
the  owner  for  action,  then  fields  2, 10,  and  11  are  completed.  Next  the 
owner,  noted  as  “Government”  in  the  descriptions,  takes  action  on  the 
submittal  in  fields  12-18. 

The  submittals  are  categorized  by  the  specification  section  and  paragraph 
to  which  they  correspond  and  by  the  type  of  information  that  is  required. 
The  submittal  type,  shown  in  Table  2-77,  identifies  what  is  to  be  provided 
with  each  submittal.  Submittals  for  complex  equipment,  engineered  or 
fabricated  components,  or  items  requiring  user  choices  (such  as  color) 
typically  have  more  than  one  submittal  type  for  a  given  item. 
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Table  2-76.  Specsintactfile  definition. 


Field 

Description 

Responsibility 

1 

The  Contractor  CPM  (Critical  Path  Method)  activity  number  as¬ 
sociated  with  the  Submittal  item 

Contractor 

2 

The  transmittal  number  assigned  by  the  contractor  to  the  Sub¬ 
mittal  when  it  is  sent  for  review 

Contractor 

3 

The  Section  number 

Designer 

4 

The  Submittal  Description  (SD)  and  number  on  the  same  row 
as  the  Section  number,  followed  by  each  Submittal  under  that 

SD  on  the  rows  below  it 

Designer 

5 

The  paragraph  number  of  the  Section  where  the  Submittal  can 
be  located 

Designer 

6 

Reviewer  -  Government  (G),  A/E 

Designer 

7 

The  date  the  contractor  is  scheduled  to  submit  the  item 

Contractor 

8 

The  date  the  contractor  requests  resolution  on  the  Submittal 

Contractor 

9 

The  date  the  material  is  needed  on  site  to  meet  the  CPM 
schedule 

Contractor 

10 

The  code  for  the  action  taken  on  the  submittal  by  the  contrac¬ 
tor’s  Quality  Control  manager 

Contractor 

11 

The  date  of  the  action 

Contractor 

12 

Date  of  Submittal  receipt 

Owner 

13 

Date  Submittal  sent  to  other  reviewer 

Owner 

14 

Date  other  reviewer  response  received 

Owner 

15 

The  code  for  the  government  action  on  the  Submittal 

Owner 

16 

The  date  of  government  action 

Owner 

17 

Date  returned  to  contractor 

Owner 

18 

Remarks 

Owner 

Table  2-77.  Specsintact  submittal  types. 


Submittal  Code 

Submittal  Type 

01 

Preconstruction  Submittals 

02 

Shop  Drawings 

03 

Product  Data 

04 

Samples 

05 

Design  Data 

06 

Test  Reports 

07 

Certificates 

08 

Manufacturer's  Instructions 

09 

Manufacturer's  Field  Reports 

10 

Operation  and  Maintenance 

11 

Closeout  Submittals 
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Once  the  submittal  file  has  been  produced  it  may  then  be  imported  into  a 
relational  database  and  use  as  the  basis  for  tracking  the  status  of  each 
submittal.  Two  systems  that  import  the  Specsintact  file  are  the  WebCM 
program  [Cooper  2006],  utilized  by  NAVFAC)  and  the  Resident  Manage¬ 
ment  System  (RMS)  program  [RMS  Center  2005],  utilized  by  USACE. 

Constraints 

There  are  many  constraints  that  have  the  potential  to  limit  the  usefulness 
of  the  COBIE  project.  Given  the  previous  failure  of  widespread  implemen¬ 
tation  other  electronic  technologies,  such  as  CADD,  at  construction  offices 
it  is  critical  that  construction  stakeholders  participate  in  the  COBIE  pro¬ 
ject  [Shen  2005].  Bjork  [2002]  identifies  four  constraints  on  the  exchange 
of  construction  data  to  operations  and  maintenance.  Eirst,  is  that  docu¬ 
ments  to  be  exchanged  are  large,  thus  requiring  increased  download  time. 
Second,  users  must  accurately  flag  information  so  that  it  can  be  easily  re¬ 
trieved.  Third,  is  that  people  in  “crisis  mode”  will  resort  to  standard  meth¬ 
ods  such  as  telephone  and  email  for  communication.  Eourth,  is  that  inter¬ 
operability  outside  specific  sets  of  proprietary  software  is  not  currently 
available. 

The  COBIE  project  plans  to  address  these  constraints  in  the  following  way. 
Eirst,  server  side  bandwidth  will  not  be  skimped  upon.  Adequate  user 
bandwidth  can  be  accommodated  by  cable  modem  or  DSL  connections  to 
all  project  participants.  Second,  users  will  be  encouraged  to  use  standard 
classification  schemes  and  folk  taxonomies  (to  be  discussed  in  the  next 
sub-section).  Third,  capturing  the  outcome  of  emergency  or  face-to-face 
conversations  should  be  simple  to  achieve  in  COBIE.  In  addition,  multiple 
channels  of  communication  should  be  integrated  and  available  through 
COBIE.  Einally,  interoperability  will  be  achieved  through  the  adoption  of 
the  COBIE  standard. 

Erom  the  point  of  view  of  standards  development  the  largest  constraint 
will  be  the  need  to  be  pragmatic  in  the  development  of  exchange  require¬ 
ments.  This  pragmatism  reflects  the  need  for  standards  to  follow  and  not 
lead  practice.  As  a  result,  COBIE  will  need  to  be  a  standard  that  allows 
evolving  mixed-modes  of  data  capture  and  exchange.  Provided  back-end 
software  systems  are  able  to  consistently  process  the  necessary  informa¬ 
tion  there  is  no  reason  that  COBIE  cannot  evolve  from  individual  file  ex¬ 
change  formats  to  fully  interoperable  lEC-based  model  exchange.  Given 
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that  the  full  adoption  of  COBIE,  and  related  technologies,  will  likely  take  a 
decade  to  accomplish,  an  incremental  approach  will  be  the  most  effective. 

Taxonomic  constraints 

Ultimately  a  building  model  will  consist  of  a  hybrid  description  of  building 
components,  products,  systems,  data,  and  instructions.  [Froese  2003].  A 
non-proprietary  format  for  building  decompositions,  the  IFC  provides  the 
most  robust  representation  of  building  decompositions.  Such  data  scheme 
will  also  need  to  include  product  libraries  and  national  standard  taxono¬ 
mies.  Classification  schemes  need  to  be  overlaid  on  the  building  model  to 
enable  the  rapid  retrieval  of  this  hybrid  data  [Gorlick  and  Froese  1999]. 

Industry  wide  metadata  classification  standard  is  key  to  ensuring  users 
will  accept  and  utilize  the  schema.  Particularly  when  the  schema  may  be 
different  from  that  used  by  a  persons’  own  firm.  An  example  of  such  a  clas¬ 
sification  scheme  being  developed  in  the  United  States  is  the  Omni  Class 
effort  developed  by  the  Construction  Specification  Institute  for  the  United 
States  [CSI  2007].  The  standard  reported  in  Brundsted  et  al.  [2007]  is  one 
of  several  European  standardization  efforts  that  currently  under  way. 

While  classification  schemes  are  needed,  it  is  not  clear  how  well  formed 
these  schemes  must  be  before  they  provide  an  effective  means  to  link 
document  metadata  to  building  models.  The  creation  of  links  between 
taxonomic  information  allows  building  data  to  be  automatically  cross- 
classified  between  various  outline  views.  In  addition,  these  schemes  pro¬ 
vide  multiple  perspectives  on  the  data  they  are  meant  to  classify.  In  one 
scheme  links  are  created  between  views  of  process,  product,  project,  ac¬ 
tors,  resource,  and  systems  [El-Diraby  et  al.  2005].  While  it  is  not  clear  if  a 
complete  cross-referencing  of  taxonomies  will  be  possible,  such  linking 
may  reduce  the  effort  required  to  fully  apply  all  views  of  a  data  model. 

One  approach  to  cross  link  standards  and  taxonomies  that  are  currently 
being  developed  in  Europe  is  to  create  dictionaries  that  provide  the  se¬ 
mantic  interpretation  of  building  terms,  components,  systems,  etc.  [CWA 
15142].  The  integration  of  OmniClass  and  an  international  dictionary  can 
serve  as  the  basis  to  streamline  the  exchange  of  building  information 
across  international  boundaries.  In  addition  the  creation  of  such  a  diction¬ 
ary  will  allow  different  standards  organizations  to  cross-walk  their  stan¬ 
dards  to  allow  translation  between  standards.  A  clear  example  of  the  need 
for  such  a  dictionary  exists  between  the  IFC  object  attributes  and  property 
sets  and  the  generic  attribute  sets  in  the  MIMOSA  standard. 
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Taxonomic  links  will  breakdown  over  time  as  technology  and  industry 
structure  change.  While  dictionary  efforts  attempt  to  keep  such  taxono¬ 
mies  current,  another  approach  should  instead  be  used  to  supplement 
formalized  taxonomies.  The  method  that  is  currently  being  used  with  the 
classification  of  amorphous  data  on  the  internet  is  called  “folksonomy” 
rhttp://en.wikipedia.org/wiki/Folksonomy1.  Through  the  vernacular  nam¬ 
ing  of  items,  by  anyone  needing  to  reference  the  item,  users  of  the  infor¬ 
mation  create  taxonomy  by  their  identification  of  keywords  and  designa¬ 
tion  of  related  information.  Examples  of  folk-taxonomies  include  the 
unmediated  discovery  that  “lift”  and  “elevator”  are  synonyms,  differences 
in  door  and  frame  assemblies  in  various  European  countries,  and  informa¬ 
tion  in  photographs  being  applied  to  some  other  purpose  than  the  main 
subject  of  the  photo. 

System  constraints 

There  are  several  constraints  to  be  considered  in  systems  that  implement 
COBIE  with  the  goal  of  reducing  the  cost  of  existing  submittal  processing 
activities.  The  first  constraint  is  that  providing  transparent  business  proc¬ 
esses  will  be  essential,  both  in  the  administrative  and  collaborative  areas. 
One  researcher  has  determined  that  establishing  and  enforcing  the  use  of 
transparent  procedures  is  the  focal  point  of  designing  quality  into  the  facil¬ 
ity  acquisition  process  [Burati  et  al.  1992]. 

In  creating  these  systems,  it  is  critical  that  the  self-organizational  behavior 
resulting  from  individual  team  members  are  reflected  [Bertelsen  2004]. 
Bertelsen  also  notes  that  it  is  the  management  of  information  flows  that 
will  enable  software  to  flexibly  adapt  to  the  complexity  of  construction 
projects  and  teams. 

With  regard  to  Building  Information  Models,  servers  form  the  basis  of  in¬ 
teractive  information  workspaces  [Liston  et  al.  2000]  that  reduce  the  need 
for  the  production,  collation,  and  reproduction.  The  model  servers  are  able 
to  answer  what  was  done,  by  whom,  and  when.  Reference  documents  such 
as  design  and  shop  drawing  reviews  will  answer  the  why  question.  Erec¬ 
tion  and  as-built  information  will  answer  the  how  question.  One  reason 
that  construction  management  software  tools  are  seen  as  a  burden  too 
many  in  the  industry  is  that  the  activities  required  to  collaboration  and 
administrate  are  separate.  If  the  collaborative  effort  needed  to  capture 
needed  data  were  provided  in  such  a  way  that  it  resulted  in  support  for 
administrative  purposes,  such  as  contractor  quality  control,  software  for 
construction  efforts  would  be  vastly  improved. 
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Bjork  [2002]  reports  that  the  benefits  of  common  file  repositories  repre¬ 
sented  0.1%  savings.  These  savings  resulted  from  reduced  meeting  and 
travel  time  and  reduction  in  copying  charges.  Transparency  of  communi¬ 
cation  and  reliance  on  the  repositories  were  increased  to  the  point  that 
team  members  were  unwilling  to  return  to  paper-based  methods.  The  au¬ 
thor’s  experience  with  ProjNet™  software  demonstrates  that  users  desire 
to  have  a  single  project  repository  that  is  directly  linked  to  all  documents 
across  space  and  time.  These  repositories  are,  by  default,  located  where 
people  do  their  work.  Software  that  implements  COBIE  must  provide  the 
capability  to  support  the  long  term  storage  and  management  of  enterprise 
documents. 

As  these  document  repositories  become  populated  (into  the  terabytes) 
search  becomes  more  critical.  Project  stakeholders  must  search  dozens  or 
hundreds  of  documents  to  find  what  they  need.  Some  researchers  have  at¬ 
tempted  to  add  database  with  product  information  however  the  lack  of 
semantic  consistency  between  design  and  construction  views  of  project  in¬ 
formation  [Shen  et  al.  2005]  results  in  differences  in  data  retrieved.  Given 
that  the  definition  of  views  required  for  ad-hoc  data  retrieval  may  not  be 
able  to  be  fully  defined,  the  use  of  “folks  taxonomies”  must  be  incorpo¬ 
rated  into  effective  construction  management  software. 

Team  constraints 

Construction  contracting  requires  parties  to  judge  decisions  according  to  a 
cooperation  or  self-optimization  scale  [Bertelsen  2004].  The  job  of  the 
project  managers,  particularly  from  the  owners’  point  of  view  should  be  to 
provide  the  resources  and  motivation  needed  to  encourage  reliable  and 
transparent  cooperation. 

A  key  question  about  resources  needed  is  who  should  provide  the  collabo¬ 
rative  platform  for  the  team.  Such  a  question  is  simple  to  answer,  but  diffi¬ 
cult  to  implement  (at  least  in  the  public  sector).  The  organization  with  the 
greatest  need  for  the  information  over  the  project  life-cycle  should  provide 
the  tools  to  capture,  link,  sort,  and  serve  that  data.  While  each  stakeholder 
will  have  some  proprietary  portion  a  shared  central  trusted  repository  of 
record  for  critical  facility  model  information  (in  whatever  form  that  takes) 
is  essential  to  initialize  the  data  for  local  team  servers. 
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3  COBIE  Project  Plan 

The  objective  of  COBIE  is  to  identify  the  information  that  can  be  captured 
during  the  prior  stages  of  facility  acquisition  in  support  facility  O&M. 

Some  of  information  need  for  O&M  is  created  during  the  architectural 
programming  phase.  A  good  example  of  such  information  is  the  inventory 
of  spaces  and  their  functional  requirements.  During  the  design  stage  the 
performance  requirements  of  materials,  products,  and  equipment  are 
specified.  During  construction  the  instantiation  of  these  requirements  re¬ 
sults  in  installed,  tested,  and  commissioned  equipment. 

Rather  than  attempt  to  capture  all  this  information  at  one  time,  the  ap¬ 
proach  of  the  COBIE  project  is  to  incrementally  identify  data  exchange  re¬ 
quirements  that,  over  time,  will  build  the  entire  COBIE  specification.  The 
selection  of  how  to  decompose  the  entire  COBIE  project  into  different 
components  is  simplified  through  the  use  of  the  Information  Delivery 
Manual  methodology,  or  IDM  [Norwegian  buildingSMART  Project  2007]. 
IDM  allows  the  creation  of  incremental,  process-based  data  exchange 
standards  that  may  be  combined  within  COBIE  and  other  exchange  proc¬ 
esses.  IDM  requires  that  individual  business  processes  and  their  related 
information  exchange  requirements  be  evaluated  and  parsed  for  their  ex¬ 
change  requirements.  As  noted  in  Section  o,  a  project  with  participation  by 
SCIP,  CSI,  and  NBIMS  is  expected  to  release  a  minimum  set  of  these  prop¬ 
erty  set  definitions.  That  project  is  currently  under  way,  with  initial  results 
expected  in  PY08. 

To  complete  COBIE  there  are  several  types  of  processes,  occurring  in  dif¬ 
ferent  parts  of  the  design  that  should  be  addressed.  These  include  Archi¬ 
tectural  Programming,  Design,  Construction  Quality  Assurance,  Supply 
Chain  Management,  and  Asset  Management.  During  each  of  these  proc¬ 
esses  some  of  the  information  created  is  relevant  to  COBIE.  These  proc¬ 
esses  also  allow  the  COBIE  project  to  be  incrementally  created. 

The  initial  COBIE  effort  focuses  on  the  construction  Quality  Assurance 
process.  This  process  captures  information  about  the  exact  physical  mate¬ 
rials,  products,  and  equipment  that  create  the  facility.  Such  information 
and  related  warranty  and  spare  parts  information  are  the  most  important 
sets  of  information  to  be  captured  by  COBIE. 
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Information  created  during  the  Architectural  Programming  phase,  which 
pertains  to  the  functional  definition  of  building  spaces,  can  be  used  to  ini¬ 
tiate  COBIE.  This  information  is  captured  as  part  of  the  pilot  COBIE  speci¬ 
fication.  This  specification  relies  on  work  currently  being  done  by  under 
the  lAI  Preliminary  Design  project  and  relies  on  the  IPC2X3  Coordination 
View.  Updated  spatial  project  data  maintained  throughout  design  and 
construction  make  it  possible  to  identify  the  as-designed  location  of  prod¬ 
ucts  and  equipment  within  the  facility. 

Prom  the  design  phase  COBIE  should  be  able  to  access  specific  perform¬ 
ance  specifications  of  equipment  to  be  installed  by  the  construction  con¬ 
tractor.  These  requirements,  in  specifications,  codes,  and  standards,  will 
be  captured  in  future  COBIE  property  sets.  This  work  will  rely  on  efforts 
currently  under  way  by  Specification  Consultants  in  Independent  Practice 
(SCIP),  the  Construction  Specification  Institute  (CSI),  and  the  Interna¬ 
tional  Code  Council  (ICC)  through  projects  being  accomplished  as  part  of 
the  National  Building  Information  Modeling  Standard  (NBIMS).  Along 
with  this  requirement  data  from  the  Design  related  to  the  functional  use 
the  material,  products,  and  equipment  and  identification  as  fixed  or  move- 
able  assets  can  be  identified. 

Additional  property  sets,  to  be  defined  during  the  course  of  the  operational 
use  of  COBIE,  will  define  full  sets  of  performance  metrics  with  all  materi¬ 
als,  products,  and  equipment  to  verify  that  the  products  submitted  and  se¬ 
lected  meet  performance  requirements.  This  information,  derived  from 
electronic  catalogues  will  streamline  purchasing  and  supply  chain  man¬ 
agement. 

A  summary  of  the  current  COBIE  project  plan  is  provided  in  Table  3-1.  The 
final  three  portions  of  the  COBIE  plan  represent  an  integration  of  COBIE 
data  with  information  captured  as  part  of  future  discussions  and  current 
NBIMS  projects. 
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Table  3-1.  COBIE  development  plan. 


Status 

Scope 

Process  Focus 

Pilot 

Replace  paper  submittals  with  electronic 
submittals.  Document  physical  samples. 
Equipment  serial  numbers  and  location. 
Warranty  and  spare  parts  linked  to  equip¬ 
ment. 

Supply  Chain, 

Quality  Assurance 

Pilot 

Extracting  equipment  location  prior  to  con¬ 
struction.  Verification  of  installed  equip¬ 
ment  during  construction. 

Architectural  Program¬ 
ming, 

Quality  Assurance 

Pilot 

Automated  identification  of  fixed  vs.  mov¬ 
able  asset  inventories 

Design, 

Asset  Management 

Pilot 

Automated  extraction  of  spatial/functional 
facility  inventory. 

Design, 

Asset  Management 

Future  Property 

Set  Definitions  in 
Progress 

Electronic  performance  specification  and 
verification  against  submittal  data. 

Design, 

Quality  Assurance 

Future  Coordina¬ 
tion  with  Code 
Checking  Project 

Automated  checking  of  submittal  perform¬ 
ance  against  relevant  codes,  standards, 
and  specifications 

Supply  Chain, 

Quality  Assurance 

Future  Property 

Set  Definitions  in 
Progress 

Automated  selection  of  materials,  products, 
and  equipment  based  on  performance 
specifications 

Supply  Chain, 

Product  Marketing 
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4  COBIE  Analysis  of  Requirements 

While  the  entire  set  of  information  needed  to  automated  the  handoff  from 
construction  to  operations  includes  information  from  various  stages  of  de¬ 
sign  and  supply  chain  management,  COBIE  focuses  on  the  exchange  of  in¬ 
formation  between  construction  and  facility  management.  The  links  be¬ 
tween  the  construction  contractor’s  supply  chain  and  the  owner 
representative’s  quality  assurance  process  are  mapped  in  COBIE  as  the 
starting  point  for  the  creation  of  the  COBIE  standard.  The  planned  addi¬ 
tions  to  the  COBIE  standard  over  time  are  identified  in  the  previous  chap¬ 
ter. 

To  create  standards  that  are  part  of  the  NBIMS,  the  IDM  process  [Norwe¬ 
gian  buildingSMART  Project  2007]  is  used.  This  chapter  describes  the  use 
of  the  IDM  and  the  resulting  process  models  verified  during  meetings  held 
in  the  spring  of  2006  as  part  of  the  NBIMS  effort.  The  focus  of  the  IDM  is 
a  reference  standard  that  maps  the  relevant  lEC  to  the  business  processes 
needed.  The  reference  standard  would  define  new  and  utilize  existing  ex¬ 
change  requirements  to  construct  the  COBIE  requirements.  Because  the 
focus  of  work  documented  in  this  report  is  the  implementation  of  COBIE 
data  exchange,  this  document  does  not  extract  new  generic  exchange  re¬ 
quirements  that  can  be  reused  in  later  IDM  activities.  The  focus  of  this  re¬ 
port  is  to  document  the  implementation  standard  needed  to  begin  using 
COBIE  as  soon  as  possible. 

The  IDM  process  defines  three  layers  of  information  exchange  specifica¬ 
tions.  The  first  layer  is  the  definition  of  specific  business  processes  that  re¬ 
quire  the  exchange  of  data  within  specific  contexts.  The  second  is  the  defi¬ 
nition  of  general  information  exchange  requirements  that  must  take  place 
at  each  step  of  the  process.  The  third  is  the  creation  of  the  actual  data  for¬ 
mat  “functional  parts”  needed  for  technical  information  exchange  among 
software  vendors.  Process  maps  and  exchange  requirements  are  described 
in  this  chapter. 

The  COBIE  standard  focuses  on  business  processes  that  link  together  the 
contractor’s  supply  chain  management  with  the  owner  representative’s 
quality  assurance  process.  The  steps  in  this  process,  and  the  final  step 
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needed  to  transfer  data  to  facility  managers,  operators,  and  maintainers 
are  shown  below: 

1.  identify  submittal  requirement 

2.  define  submittal  schedule 

3-  transmit  submittal 

4-  approve  submittal 

5.  install  equipment 

6.  commission  equipment 

7.  provide  warranties 

8.  provide  spare  parts  sources 

9.  transmit  handover  information. 

Each  COBIE  process  is  described  in  the  paragraphs  that  follow.  Each  sec¬ 
tion  begins  with  an  overview  of  the  process  and  discussion  of  issues  that 
are  explicitly  within  or  outside  the  scope  of  the  COBIE  specification.  Eol- 
lowing  this  information,  activities  comprising  the  process  relevant  to 
COBIE  are  described  and  documented  in  a  business  process  diagram. 

Several  issues  of  a  general  nature  apply  to  each  of  these  processes  as  iden¬ 
tified  by  attendees  at  the  29  March  2006  COBIE  meeting  in  Washington, 
DC.  These  issues  are: 

Many  of  the  information  exchange  processes  require  that  information  be 
initially  provided  in  a  “batch”  mode  that  contains  many  individual  records. 
As  work  continues  on  the  project  “packet”  transitions  also  need  to  occur  to 
either  create  new  data  against  the  “batch”  set  of  information  or  to  update 
the  “batch”  information  provided. 

Not  all  submittals  are  included  in  the  COBIE  project.  Eor  example  physical 
samples  will  continue  to  need  to  be  provided,  as  specified.  COBIE  will, 
however,  capture  data  about  physical  submittals  including  photographs, 
test  reports,  etc... 

Design-build  contracting  methods  may  not  explicitly  list  submittals.  As  a 
result,  owners  need  to  be  clear  about  the  applicability  of  COBIE  for  design 
build  requests  for  proposals.  One  reasonable  approach  discussed  at  the  29 
March  2006  meeting  was  to  require  submittals  that  document  product  in¬ 
formation  on  all  materials,  products,  or  equipment  that  confers  a  warranty 
to  the  owner. 
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Regarding  the  legal  implication  of  electronic  documents,  it  was  felt  that 
COBIE  should  use  existing  legal  frameworks.  Under  the  current  approach 
related  to  the  exchange  of  Computer  Aided  Drafting  and  Design  (CADD) 
drawings,  the  paper  copies  “govern.”  Electronic  CADD  files  are  provided 
for  information  only.  Given  that  the  purpose  of  COBIE  is  to  eliminate  pa¬ 
per  submissions,  the  implication  of  current  legal  frameworks  is  not  clear, 
and  for  the  time  being,  outside  the  scope  of  the  COBIE  project.  The  issue 
of  requiring  a  single  paper  “copy  of  record”  or  fully  eliminating  all  paper 
submittals  will  be  left  up  to  local  legal  findings  and  implementation  speci¬ 
fications. 

Identify  submittal  requirements 

Overview 

The  first  stage  in  the  identification  of  submittal  requirements  during  con¬ 
struction  is  the  transfer,  from  the  lead  designer  to  the  construction  man¬ 
ager,  the  required  list  of  items  that  must  be  submitted  by  the  contractor. 
This  information  is  called  the  submittal  log.  This  log  identifies  each  sub¬ 
mittal  and  links  the  submittal  to  the  specification  section  in  which  the  re¬ 
quirement  for  the  submittal  is  referenced.  The  purpose  of  the  submittal  is 
to  provide  the  information  necessary  for  the  construction  manager  to  vali¬ 
date  that  materials,  products,  equipment,  and  systems  meet  the  minimum 
performance  standards  identified  in  the  construction  documents.  The 
purpose  of  the  submittal  lot  is  to  track  the  team’s  progress  with  regard  to 
submitting,  evaluating,  and  (if  needed)  approving  submittals. 

The  steps  needed  to  complete  this  process  as  relate  to  COBIE  are  provided 
below. 

Issues  within  COBIE  scope 

The  production  of  the  construction  contractor  submittal  register  by  the 
lead  designer  initiates  the  transmission  of  the  register  through  COBIE. 

This  production  takes  place  within  software  systems  used  for  the  genera¬ 
tion  of  construction  specifications. 

Issues  outside  COBIE  scope 

Although  the  COBIE  project  begins  its  definition  of  information  exchange 
with  the  submittal  log,  the  material,  products,  equipment,  and  systems 
identified  in  the  log  are  not  created  at  this  stage.  During  previous  phases  of 
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design  decisions  are  made  as  to  the  requirements  for,  placement  of,  and 
alternatives  to  materials,  products,  and  equipment.  The  capture  of  these 
decisions,  and  resulting  exchange  of  a  robust  set  of  data,  is  not  considered 
in  this  project. 

Unresolved  scope  issues 

One  way  to  facilitate  the  production  of  COBIE  information  exchange  is  to 
require  the  designer  to  provide  a  spatial  layout  for  the  building  that  lists 
each  facility,  floor,  and  room  number.  This  information  (created  either 
during  planning  or  design)  forms  the  basis  of  assigning  equipment  and 
products  to  specific  spaces.  Given  that  the  designer  is  the  responsible  party 
that  creates  this  data,  it  makes  sense  that  contractors  not  reproduce  the 
information  later  in  the  COBIE  business  process. 

Process  description 

Construction  docs 

The  Identify  Submittal  Requirements  process  (Eigure  4-1)  begins,  on  de- 
sign-bid-build  contracts,  with  the  completion  of  construction  documents. 
At  that  stage  the  complete  set  of  submittal  requirements  is  known  based 
on  the  construction  documents. 

The  creation  of  a  complete  set  of  construction  documents,  during  design- 
build  contracts  occurs  at  the  end  of  the  design-build  contract.  Depending 
on  the  specific  type  of  design-build  contract  it  should,  however,  be  possible 
to  pre-define  data  requirements  for  materials,  products,  and  equipment 
that  is  expected  to  result  in  warrantable  end-products. 
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Figure  4-1.  Identify  Submittai  Requirements  process  chart. 
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Create  register 

With  the  provision  of  the  whole,  or  part  of  the  construction  documents, 
the  actual  outline  of  the  submittals  required  can  be  automatically  ex¬ 
tracted  from  many  specification  writing  software  packages.  Table  4-1  pre¬ 
sents  the  optional  and  required  information  that  should  be  provided  with 
the  submittal  register.  The  first  part,  the  optional  data,  allows  the  specifi¬ 
cation  register  item  to  reference  an  external  set  of  reference  submittals. 
The  second  set  of  data,  the  required  data,  identifies  the  minimum  informa¬ 
tion  needed  to  create  the  submittal  register.  The  required  data  includes  the 
information  provided  by  the  specification  writing  software,  as  described 
previously. 


Table  4-1.  Submittal  register  data  requirements. 


Name 

Type 

Reqd/Opt 

Description 

RegisterSourceUID 

String 

Opt. 

Link  to  master  set  for  reference  set 

RegisterSourceURL 

String 

Opt. 

Link  to  specific  reference 

RegisterSourceTitle 

String 

Opt. 

Text  title  of  specific  reference 

RegisterRefMajorTitle 

String 

Reqd. 

Enabling  reference 

RegisterRefMajorHead 

String 

Reqd. 

Text  of  major  heading 

RegisterRefMinorHead 

String 

Reqd. 

Text  of  minor  heading 

RegisterltemID 

String 

Reqd. 

Project-specific  ID 

RegisterltemType 

Reference 

Reqd. 

One  of  11  types  of  submittals 

RegisterltemReview 

Reference 

Reqd. 

Owner  approve/Contractor  certify 

RegisterltemTitle 

String 

Reqd. 

Title  of  submittal 

RegisterltemBy 

Contact 

Reqd. 

Author’s  contact  information 

RegisterltemOn 

Date 

Reqd. 

Date  item  created 

While  typical  specifications  based  on  design-bid-build  specifications  re¬ 
quire  submittals  based  on  documents  such  as  Unified  Facilities  Guide 
Specifications  (UFGS),  other  types  of  codes  and  standards  may  also  re¬ 
quire  submittals.  The  “RegisterRefMajorTitle”  field  allows  the  creator  of 
the  submittal  register  to  identify  the  source  of  the  submittal  requirement. 
The  “RegisterRefMajorHead”  and  “RegisterRefMinorHead”  fields  provide 
sufficient  information  to  access  the  requirement  within  the  referenced  re¬ 
quirement  document.  For  example,  if  the  referenced  document  is  the 
UFGS,  RegisterRefMajorHead  would  equal  the  specification  section  and 
RegisterRefMinorHead  would  reference  the  section  number  of  the  section. 

“RegisterltemID”  provides  a  reference  to  a  specific  submittal  that  will  be 
provided  on  the  project.  This  internal  reference  also  may  be  helpful  when 
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linking  submittals  directly  to  building  objects  in  a  future  Building  Infor¬ 
mation  Model.  “RegisterltemType”  identifies  one  of  the  ii  types  of  submit¬ 
tals  previously  referenced  in  this  report.  “RegisterltemReview”  references 
who  will  be  taking  action  on  the  submittal.  Typically,  the  action  will  be 
“Owner  Approval”  or  “Contractor  Certified,”  but  other  options  may  be  pos¬ 
sible  in  the  future.  Therefore,  the  selection  is  not  hard-coded  in  the  data 
exchange  requirement.  The  “RegisterltemTitle”  field  provides  a  descrip¬ 
tion  of  the  time  to  be  submitted. 

The  information  exchange  should  include  the  contact  information  such  as 
name,  company,  address,  telephone,  and  email  of  the  person  who  specified 
the  requirement  as  well  as  the  date  one  which  the  requirement  was  identi¬ 
fied.  In  the  case  of  a  single  export  both  of  these  values  may  be  the  same, 
i.e.,  the  engineer  or  architect  who  pressed  the  button  to  get  the  export  file. 
There  may,  however,  be  many  different  authors  as  these  requirements  are 
compiled  by  individual  consultants  and  designers. 

Optional  items  in  Table  4-1  allow  specific  submittal  to  be  linked  to  the 
source  document.  The  “RegisterSourceUID”  is  a  universal  identifier  pro¬ 
vided  by  the  source  document  publisher.  This  UID  may  provide  a  link  back 
to  the  master  list  from  which  all  submittals  are  created.  The  “Register- 
SourceURL”  provides  a  locator  for  the  specific  source  document.  The  type 
of  document  and  protocol  will  also  be  identified  as  part  of  this  data  field. 
The  “RegisterSourceTitle”  field  provides  the  generic  title  for  the  type  of 
reference  that  created  the  requirement.  For  example  the  “RegisterSour¬ 
ceTitle”  would  be  set  to  “UFGS”  for  requirements  identified  as  a  result  of 
Unified  Facilities  Guide  Specifications. 

Receive  register 

Once  the  register  has  been  created,  the  designer  submits  the  register  to  the 
construction  manager  or  owner’s  representative.  This  submittal  should  be 
supported  in  a  ‘batch’  mode  so  that  the  entire  set  of  submittals  can  be  im¬ 
ported  at  one  time. 

Import  submittal  register 

After  receipt  of  the  register  the  construction  manager  or  owner’s  represen¬ 
tative  will  need  to  import  the  data  into  their  submittal  register  software 
package.  The  purpose  of  this  register  is  to  serve  as  the  log  for  all  submit- 
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tals.  The  primary  job  of  this  log  is  to  identify  exceptions  with  regards  to 
items  not  approved  by  the  contractor’s  “required  by”  dates. 

Verify  register 

Once  the  submittal  register  has  been  imported  into  the  construction  man¬ 
ager  or  owner’s  representative,  submittal  register  software  package  will 
need  to  ensure  that  the  information  is  correct  as  transmitted.  Given  the 
goal  of  eliminating  paper  transfer  of  submittal  related  information,  the  de¬ 
signer  should  be  given  view-only  access  to  the  construction  manager  or 
owner’s  representative  submittal  register  software  package  to  ensure  that 
the  information  therein  is  correct.  Future  software  systems  used  in  con¬ 
struction  management  offices  may  allow  designers  providing  CM,  or  re¬ 
lated  services,  to  accept  the  electronic  submittal  register. 

Update  register 

Prior  to  the  start  of  construction  full  ‘batch’  mode  updates  should  be  able 
to  wipe  and  recreate  the  whole  set  of  submittals  for  the  project  in  question. 
Once  the  contractor  adds  data  to  an  approved  register,  those  records  can¬ 
not  be  changed  in  a  ‘batch’  mode  of  operation. 

Changes  to  the  submittal  register  based  on  a  ‘packet’  level  of  exchange  may 
be  made,  however,  the  process  may  require  that  an  approval  process  for 
incoming  ‘deviations’  be  approved  by  the  construction  manager  or  owner’s 
representative  prior  to  the  change  being  accepted. 

Approvals  of  changes  to  the  submittal  register  are  explicitly  outside  the 
scope  of  COBIE  since  these  changes  could  result,  depending  on  the  timing 
of  the  change,  construction  change  orders. 

Define  submittal  schedule 

Overview 

The  process  for  defining  the  submittal  schedule  is  shown  in  Figure  4-2. 
Once  a  project’s  submittal  register  has  been  accepted  by  the  construction 
manager  or  owner’s  representative,  the  log  is  provided  to  the  construction 
contractor  to  coordinate  submittal  requirements  with  their  Critical  Path 
Method  (CPM)  scheduling  program.  The  contractor’s  analysis  of  their 
schedule  results  in  the  identification  of  submit-on,  approve-by,  and 
needed-on  dates  to  be  included  in  the  submittal  log. 
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With  the  exception  of  submittals  provided  during  the  mobilization  phase 
of  a  standard  design-bid-build  project,  construction  submittals  are  not 
generally  permitted  until  a  submittal  schedule  has  been  approved. 

Subprocesses  within  scope 

The  submittal  log  must  be  passed  from  the  construction  manager  or 
owner’s  representative  to  the  prime  contractor  and  back.  The  exchange  of 
information  from  the  construction  contractor  and  prime  contractor  data 
systems  is  part  the  scope  of  this  business  process. 

Subprocesses  out  of  scope 

The  direct  linkage  between  construction  schedule  activities  and  submittal 
register  entries  is  frequently  discussed  in  terms  of  major  “feature  of  work.” 
For  example,  several  submittals  across  different  reference  sections  may 
need  to  be  approved  prior  to  starting  a  significant  feature  of  work.  Con¬ 
crete  mix  design,  placement  plans,  and  rebar  may  all  need  to  have  submit¬ 
tals  prior  to  the  start  of  cast-in-place  concrete  construction.  Coordinating 
submittals  for  various  features  of  work  that  reflect  a  project’s  “work  break¬ 
down  structure”  are  outside  the  scope  of  this  information  exchange. 


Designer 


CM/Owner's  Rep  Prime  Contractor 


Subcontractor 


Supplier 


Manufacturer 


m 


2.1  to  2.8  Add  scheduled  dates  to  submittal  log 


Communications  will  need  to  be  supported  In  both  a  batch 
mode,  to  initialize  the  schedule  dates,  and  in  a  message 
mode,  to  provide  individual  change  transactions. 


Focus  of  this  process  is  to  obtain  the  Contractor's  schedule 
for  submitting  each  item,  \A(hen  each  Item  must  ordered, 
and  when  the  material,  product,  or  equipment  is  to  be 
delivered  to  the  site. 


Use  of  CPM  scheduling  software  links  can,  ultimately, 
provide  real-time  updates  to  schedule  dates.  This 
capability  is  not  included  in  the  scope  of  COBIE  I  or  II. 


Figure  4-2.  Define  Submittal  Schedule  process  chart. 


ERDC/CERL  TR-07-30 


ERDC/CERLTR-07-30 


75 


Process  description 

Basic  register 

The  process  of  defining  the  submittal  schedule  begins  with  an  approved 
submittal  register  outline,  provided  by  the  previous  process. 

Export  register 

The  construction  manager  or  owner’s  representative  exports  a  copy  of  the 
submittal  register  outline  for  transmission  to  the  prime  construction  con¬ 
tractor  in  ‘batch’  mode.  The  format  for  this  exchange  is  exactly  that  created 
under  the  previous  process.  In  keeping  with  the  need  for  a  pragmatic  “im¬ 
plementation”  standard,  the  format  for  the  register  may  be  Excel,  ifcXML, 
or  other  agreed-upon  format. 

Receive  register 

The  prime  construction  contractor  receives  the  register  in  the  office  ap¬ 
propriate  to  manage  that  project.  Depending  on  the  size  of  the  contractor’s 
office  and/or  project  size  the  contractor  may  have  dedicated  project  office 
engineering  staff,  a  site  manager,  or  have  a  shared  purchasing  department 
manage  the  submittal  register.  It  is  expected  that  the  construction  man¬ 
agement  software  tools  used  by  individual  team  members  are  able  to  ac¬ 
cept  the  register  file  and  process  the  information  consistently. 

Update  register 

Once  this  office  receives  the  register  and  verifies  that  it  contains  the  re¬ 
quired  information,  then  the  appropriate  prime  contractor  representatives 
can  develop  the  plan  for  completing  these  submittal  requirements.  Sub¬ 
contractors  (some  of  whom  may  not  be  identified  at  the  phase  of  the  con¬ 
tract  when  the  register  and  schedule  are  created)  may  also  need  to  provide 
input  to  the  submittal  register.  As  a  result,  the  prime  contractor  may  also 
allow  the  data  to  be  fed  forward  to  authorized  subcontractor  personnel. 

The  data  required  to  be  provided  by  the  prime  contractor  back  to  the  con¬ 
struction  manager  or  owner’s  representative  is  shown  in  Table  4-2.  The 
first  required  register  data  “RegisterltemID”  is  a  read-only  field  to  the 
prime  contractor  and  subcontractors.  This  ID  is  unique  to  the  project 
submittal  register  (but  the  value  may  be  repeated  on  other  projects).  The 
needed  schedule  dates  for  submission,  approval,  and  delivery  are  provided 
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based  on  the  CPM  schedule  activity.  The  final  set  of  data  is  the  contact  in¬ 
formation  for  the  prime  contractor  or  subcontractor  who  made  the  request 
and  the  date  on  which  the  request  was  made. 


Table  4-2.  Submittal  Schedule  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

RegisterltemID 

String 

ReadOniy 

Project-specific  ID 

RegisterScheduleCPMTask 

String 

Reqd. 

Construction  scheduie  iink 

RegisterScheduleSubmitBy 

Date 

Reqd. 

Pianned  date  for  item  transmittai 

RegisterSch  ed  u  1  eApproveBy 

Date 

Reqd. 

Needed  date  for  item  approvai 

RegisterScheduleDeliveryBy 

Date 

Reqd. 

Needed  date  for  on-site  materiai 

RegisterScheduledBy 

Contact 

Reqd. 

Author’s  contact  information 

RegisterScheduledOn 

Date 

Reqd. 

Date  action  taken 

Export  (updated)  register 

The  contractor  will  compile  its  own  information  and,  possibly,  the  infor¬ 
mation  provided  by  its  subcontractors,  and  submit  it  to  the  construction 
manager  or  owner’s  representative. 

Receive  (updated)  register 

The  construction  manager  or  owner’s  representative  receives  the  batch  file 
of  the  prime  contractors  submittal  schedule  and  imports  that  information 
into  the  construction  manager  or  owner’s  representative  software  tool. 

Notify  contractor 

The  construction  manager  or  owner’s  representative  evaluates  the  content 
of  the  prime  contractor’s  updates  and  provides  notification  back  to  the 
contractor  indicating  the  acknowledgement  or  non-concurrence  with  the 
submittal  schedule  as  provided.  Table  4-3  identifies  the  information  ex¬ 
change  requirements  to  facilitate  this  discussion. 


Table  4-3.  Submittal  Schedule  Approval  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

RegisterltemID 

String 

ReadOniy 

Project-specific  ID 

Regi  ste  rStatu  sTy  pe 

Reference 

Reqd. 

Contractor  certified/Non-Concur 

RegisterStatusBy 

Contact 

Reqd. 

Author’s  contact  information 

RegisterStatusOn 

Date 

Reqd. 

Date  action  taken 

RegisterStatusNote 

Memo 

Opt./Reqd. 

Required  if  “Non-Concur” 
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As  with  the  previous  information  exchange  the  “RegisterltemID”  is  a  pro¬ 
ject  specific  ID  number  that  can  track  a  submittal  back  to  its  original  re¬ 
quirement.  “RegisterStatusType”  is  the  identification  of  the  status  of  the 
approval  of  the  register  schedules  at  this  ‘atomic’  level.  Next,  the  contact 
information  of  the  person  completing  the  transaction  and  the  date  on 
which  the  status  was  evaluated  is  provided.  If  there  is  a  “Non-Concur” 
status,  then  the  construction  manager  or  owner’s  representative  must  pro¬ 
vide  the  “RegisterStatusNote”  data  that  explains  the  issue  of  concern  to  the 
construction  manager. 

If  helpful,  there  may  be  another  field  added  that  is  currently  not  shown  in 
Table  4-3.  The  possible  “RegisterStatusCode”  may  give  a  preset  list  of  val¬ 
ues  for  reasons  for  which  submittals  may  be  returned  with  a  status  of 
“Non-Concur.”  One  example  may  be  cases  where  dates  required  provide 
insufficient  time  (under  5  or  10  business  days)  for  approval.  Intelligent 
agents  reviewing  the  schedule  could  automatically  deny  such  schedules 
and  provide  standard  reason  codes. 

Receive  notification 

In  this  process  the  submittal  register  schedule  entries  are  returned  to  the 
prime  contractor  who,  in  the  case  of  a  “contractor  certified”  status,  pro¬ 
ceeds  to  execute  the  project.  In  the  case  of  a  “non-Concur”  status,  the 
prime  contractor  will  need  to  initiate  an  off-line  (as  far  as  COBIE  is  con¬ 
cerned)  dialog  regarding  the  issue,  and  resubmit  a  change  that  can  be 
agreed  upon  by  the  construction  manager  or  owner’s  representative. 

Update  scheduie  (not  pictured) 

Not  included  in  the  diagram  is  the  method  for  updating  the  schedule  over 
time.  There  must  be  several  business  rules  governing  the  updating  of  this 
information.  First,  once  a  submittal  has  been  provided  the  data  regarding 
planned  dates  may  not  be  changed.  Second,  all  changes  to  the  dates  must 
be  approved  by  the  construction  manager  or  owner’s  representative. 

A  standard  expectation  is  that  schedule  dates  should  not  change  more 
than  once  per  month  and  be  synchronized  with  changes  to  the  CPM 
schedule.  While  direct  synchronization  with  the  CPM  schedule  is  not  re¬ 
quired,  reports  that  compare  data  between  the  schedule  and  related  CPM 
schedule  tasks  should  provide  “reasonable”  results.  For  example,  the  ex¬ 
pected  material  delivery  date  must  be  before  the  related  CPM  schedule 
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task  can  begin  work.  Submittal  and  approval  activities  must  provide  suffi¬ 
cient  time  prior  to  the  delivery  of  equipment  to  allow  review. 

Transmit  submittal 

Overview 

During  this  process  the  prime  contractor’s  quality  control  representative 
or  project  manager  receives  information  on  each  submittal  required  in  the 
submittal  log  from  the  prime  contractor’s  purchasing  offices,  subcontrac¬ 
tors’,  suppliers,  or  manufacturer  staff.  This  information  is  packaged  by  the 
prime  contractor  and  provided  to  the  construction  manager  or  owner’s 
representative  for  review. 

Subprocesses  within  scope 

The  most  basic  type  of  process  for  the  creation  of  a  draft  submittal  by  con¬ 
tracting  stakeholders  and  then  submitting  that  information  to  the  con¬ 
struction  manager  or  owner’s  representative  is  covered  in  the  scope  of  this 
process 

Subprocesses  out  of  scope 

The  prime  contractor  is  responsible  to  ensure  that  subcontractors  receive 
information  from  suppliers  and  manufacturers  in  a  timely  fashion.  The 
time-management  business  processes  required  are  not  included  in  this 
scope  of  work. 

Process  description 

Evaluate  requirement 

As  shown  by  process  3.1  (Figure  4-3),  following  the  completion  of  the  sub¬ 
mittal  schedule  individual  submittals  are  provided  by  the  prime  contractor 
or  subcontractor.  Information  for  the  submittal  is  often  provided  directly 
by  the  supplier  or  manufacturer.  The  process  of  creating  and  transmitting 
a  submittal  begins  with  the  prime  contractor’s  evaluation  the  submittal 
requirement.  Based  on  this  evaluation,  preparation  of  the  submittal  pack¬ 
age  may  be  completed  by  the  prime  or  subcontractor.  Following  the 
evaluation  the  responsible  party  the  submittal  is  assigned  to  the  appropri¬ 
ate  responsible  party. 
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If  COBIE  is  to  support  the  processing  of  submittal  information,  then  stan¬ 
dard  for  the  exchange  of  submittal  data  prior  to  the  actual  transmission  of 
the  submittal  may  be  needed.  The  information  required,  to  support  this 
specific  process,  is  information  that  allows  submittals  to  be  assigned  to  in¬ 
dividual  team  members.  There  are  two  types  of  information  needed  for 
this  assignment.  The  first  is  the  identification  of  the  individuals  on  the 
team. 

Three  tables  (Table  4-4  -  Table  4-6)  are  needed  to  capture  individual  team 
member  information,  as  shown  below.  This  information,  while  not  part  of 
a  specific  packet  that  transfers  responsibility,  is  needed  as  part  of  any  sys¬ 
tem  implementing  the  COBIE  standard.  An  independent,  authoritative 
source  for  user  information  is  needed,  but  providing  such  a  source  is  out¬ 
side  the  scope  of  COBIE. 


Table  4-4.  Person  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

PersonID 

String 

ReadOniy 

Person-specific  ID 

PersonAddressID 

String 

Reference 

Reference  to  AddressItemID 

PersonOrganizationID 

String 

Reference 

Reference  to  OrganizationID 

PersonFamilyName 

String 

Reqd. 

PersonGivenName 

String 

Reqd. 

PersonMiddleNames 

String 

Opt 

PersonPrefixTitles 

String 

Reqd. 

PersonSuffixTitles 

String 

Reqd. 

PersonTelephone 

String 

Reqd. 

PersonEmail 

String 

Reqd. 

Table  4-5.  Organization  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

OrganizationID 

String 

ReadOniy 

Address-specific  ID 

OrganizationParentID 

String 

Reference 

Reference  to  OrganizationID 

OrganizationAddressID 

String 

Reference 

Reference  to  AddressItemID 

OrganizationName 

String 

Reqd. 

OrganizationNote 

Memo 

Opt. 
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Table  4-6.  User  Address  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

AddressID 

String 

ReadOniy 

Address-specific  ID 

AddressLinel 

String 

Reqd./Opt. 

Reqd.  if  PostaiBox  biank 

AddressLine2 

String 

Opt. 

Ad  dress  Postal  Box 

String 

Reqd./Opt. 

Reqd.  if  AddressLinel  biank 

AddressTown 

String 

Reqd. 

City,  or  town 

AddressRegionState 

String 

Reqd. 

Region,  e.g.,  U.S.  state  name 

AddressPostalCode 

String 

Reqd. 

In  the  US,  zip  code 

AddressCountry 

String 

Reqd. 

Standard  country  iist  inciuded 

Given  that  the  team  members  can  be  identified  and  contacted,  information 
provided  in  the  previous  tables,  matching  the  team  members  to  the  spe¬ 
cific  submittal  is  the  next  set  of  data  that  must  be  captured.  Table  4-7  iden¬ 
tifies  the  data  needed  to  express  the  assignment  of  individual  team  mem¬ 
ber  with  a  specific  submittal  item. 


Table  4-7.  Submittal  Assignment  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

AssignID 

String 

ReadOniy 

Assignment-specific  ID 

Assign  ItemID 

String 

Reference 

Reference  to  RegisterltemID 

AssignUserlD 

String 

Reference 

Reference  to  Person  ID 

Assign  By 

Contact 

Reqd. 

Assignor’s  contact  information 

AssignOn 

Date 

Reqd. 

Date  assignment  made 

Implementations  of  the  assignment  function  should  allow  those  assigned 
to  a  specific  document  to  directly  provide  the  draft  submittal  documents. 
Only  the  prime  contractor’s  designated  staff  has  the  ability  to  manage  the 
entire  submittal  process  or  transmit  the  documents  to  the  owner’s  repre¬ 
sentative  or  construction  manager. 

Receiving  request  for  submittai 

The  person  receiving  the  request  for  submittal  may  update  that  assign¬ 
ment  by  indicating  their  availability  or  applicability  to  completing  the  task 
(see  Table  4-8).  Implementation  of  the  assignment  must  allow  the  user 
who  is  assigned  to  (1)  reassign  the  item  to  another  person  at  their  office, 

(2)  indicate  that  they  are  not  the  right  person  to  complete  the  job,  (3)  indi¬ 
cate  that  they  will  be  out  of  the  office  during  the  timeframe  required,  or  (4) 
to  say  that  they  have  completed  the  task.  There  may  also  be  multiple  peo¬ 
ple,  even  from  different  organizations,  responsible  to  draft  the  submittal. 
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The  separation  of  the  task  for  the  preparation  of  the  submittal  package 
from  the  actual  submittal  is  needed  so  that  those  preparing  the  submittal 
can  update  the  status  of  their  own  work  without  affecting  the  status  of  oth¬ 
ers  or  that  of  the  underlying  submittal. 


Table  4-8.  Submittal  Assignment  Status  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

StatusID 

String 

ReadOniy 

Assignment-status  specific  ID 

StatusAssignID 

String 

Reference 

Assignment-specific  Assign  ID 

StatusCode 

Reference 

Reqd. 

Current  status  of  the  assignment 

StatusNotation 

Memo 

Opt. 

Additionai  status  information 

StatusBy 

Contact 

Reqd. 

Assignee’s  contact  information 

Statu  sOn 

Date 

Reqd. 

Date  action  taken 

Processing  request  for  submittal 

Once  the  correct  team  member  has  been  assigned  and  is  preparing  the 
draft  submittal,  the  submittal  is  prepared  by  gathering  the  required  infor¬ 
mation  and  submitting  that  information  to  the  prime  contractor.  The  spe¬ 
cific  format  for  the  data  to  be  gathered  will  begin  at  a  minimum  level  of 
Portable  Document  Format  (PDF)  files.  As  required,  individual  submittal 
may  have  additional  requirements  for  information  transfer.  The  specific 
requirements  are  not  described  in  this  section. 


Figure  4-3.  Transmit  Submittai  process  chart. 
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Receive  draft 

Once  the  submittal  has  been  processed  by  the  assigned  users,  and  trans¬ 
mitted,  as  a  draft  submittal  to  the  prime  contractor,  the  status  of  the  as¬ 
signment  should  be  changed  to  indicate  that  the  submittal  is  waiting  re¬ 
view  by  the  prime  contractor  prior  to  being  transmitted  to  the  owner’s 
representative  or  construction  manager.  Data  required  to  represent  this 
transactional  information  was  noted  in  a  previous  table. 

While  tracking  information  on  the  source  of  submittal  data  will  be  of  in¬ 
terest  to  the  prime  contractor,  such  information  should  not  be  part  of  the 
transmittal  since  the  transmittal  is  required  to  occur  as  part  of  the  formal 
contractor  quality  control  process. 

Evaluate  draft 

The  prime  contractor  will  review  the  draft  submittal  package  and  may  re¬ 
quire  that  the  package  be  revised.  If  this  is  the  case  a  new  assignment  can 
be  created  that  documents  the  updated  requirement.  Data  required  to  cap¬ 
ture  this  reassignment  has  already  been  defined. 

Transmit  documents 

When  the  prime  contractor  has  either  completed  their  own  submittal  or 
reviewed  the  draft  submittal  package  provided  by  their  subcontractors, 
suppliers,  and  or  manufacturers,  then  they  are  prepared  to  transmit  the 
package  of  documents  to  the  owner’s  representative  or  construction  man¬ 
ager. 

The  tool  used  by  the  owner’s  representative  or  construction  manager  to 
capture  the  submittal  data  must  capture  source  of  each  file  sent,  and  addi¬ 
tionally  required  data,  along  with  the  related  submittal. 
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Table  4-9.  Transmittal  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

TransmittallD 

String 

ReadOniy 

Transmittai-specific  ID 

TransmittalltemID 

String 

Reference 

Reference  to  RegisterltemID 

TransmittalPersonID 

String 

Reference 

Reference  to  PersonID 

TransmittalRevisionID 

String 

Reference 

Reference  to  Transmittal  ID 

TransmittalRevisionNo 

String 

Required 

Order  of  Revision  submitted 

TransmittalOrderlD 

Integer 

Required 

Order  of  Items  submitted 

TransmittalPrettyName 

String 

Reqd. 

File  Name  of  the  File  Sent 

TransmittalFileName 

String 

Private 

Local  File  name 

TransmittalOn 

Date 

Reqd. 

Resubmit  documents  (not  pictured) 

Since  items  within  a  given  transmittal  may  need  to  be  revised  and  resub¬ 
mitted,  the  previous  table  provides  the  required  data  fields  to  keep  track  of 
versioning  of  submittal  documents. 

Approve  submittal 

Overview 

The  process  for  owner’s  action  on  a  submittal  depends  on  the  type  of  sub¬ 
mittal  being  provided  Figure  4-4).  There  are  three  types  of  initial  submit¬ 
tals  that  will  be  considered  in  this  process.  The  first  type  of  submittal  de¬ 
scribes  project  specific  engineered  components.  These  submittals  require 
the  provision  of  shop  drawings,  fabrication  drawings,  erection  instruc¬ 
tions,  and  as-installed  documentation.  Items  such  as  these  are  required  to 
be  approved  by  the  A/E  firm. 

The  second  type  of  initial  submittal  in  this  process  is  those  materials, 
products,  and  equipment  that  can  be  fully  described  by  manufacturer  pro¬ 
vided  data  such  as  “cut-sheets.”  Information  for  these  submittals  will  be 
provided  in  a  file-based  format  that  contains  the  appropriate  manufac¬ 
turer’s  instructions.  In  addition  to  the  electronic  equivalent  the  currently 
processed  paper  submissions;  attributes  will  also  be  defined  for  each  type 
of  item.  Attribute  sets  will  be  comprised  of  several  parts.  The  first  type  of 
attributes  defines  the  source  of  the  document  such  as  owner  and  date 
submitted.  The  second  type  of  attribute  describes  the  performance  charac¬ 
teristics  of  the  item  submitted. 
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The  third  type  of  submittal  is  requires  submission  of  physical  samples  or 
product  data.  Materials  that  require  color  selection  are  a  good  example  of 
this  type  of  submittal. 

Subprocesses  within  scope 

In  general,  COBIEi  will  include  “source”  attributes  and  “characteristics” 
metadata  associated  product-independent  attributes  such  as  warranty  re¬ 
quirement,  spare  parts  suppliers,  etc.  COBIE2  will  include  the  minimum 
set  of  product-specific  characteristics  needed  to  ensure  compliance  with 
specifications,  codes,  and  standards. 

Subprocesses  out  of  scope 

Attribute  data  for  physical  samples  will  be  considered  out  of  scope  how¬ 
ever  the  cut-sheet  information  associated  with  the  physical  samples  is 
within  scope. 

Process  description 

Receive  submittal 

When  the  owner’s  representative  or  construction  manager  receives  the 
submittal  the  submittal  register  date  fields  documenting  the  ‘actual’  dates 
corresponding  to  the  planned  transmittal  date  must  be  updated. 


Figure  4-4.  Approve  Submittal  process  chart. 


00 
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Table  4-10.  Submittal  Receipt  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

RegisterltemID 

String 

Readonly 

Project-specific  ID 

RegisterSubmitPersonID 

Reference 

Readonly 

Reference  to  PersonID 

RegisterSubmitOn 

Date 

Reqd. 

Date  submitted 

RegisterSubmitlsCertified 

Boolean 

Reqd. 

Ctr.  Certified  to  meet  rqmt. 

RegisterSubmitlsDeviation 

Boolean 

Reqd. 

Contains  deviation 

RegisterSubmitNote 

Memo 

Opt. 

Required  if  deviation 

Assign  submittal  evaluation 

Once  the  submittal  has  been  received,  the  owner’s  representative  or  con¬ 
struction  manager  determines,  from  the  original  submittal  register,  who  is 
to  evaluate  the  submittal.  A  submittal  assignment  is  made  using  the  data 
requirements  identified  in  the  previous  section. 

Evaluate  submittal 

The  action  code  provided  on  submittals  evaluated  by  owner/other  and/or 
designers  are  noted  on  the  submittal  evaluation  assignment.  Since  there 
may  be  multiple  evaluations  of  a  given  submittal,  the  owner’s  representa¬ 
tive  or  construction  manager  will  need  to  separate  the  recommendation 
made  by  external  reviewers  from  that  provided  back  to  the  prime  contrac¬ 
tor. 

One  issue  to  keep  in  mind  during  this  process  is  that  when  the  entire  sub¬ 
mittal  is  approved,  all  the  transmitted  files  are  also  approved.  It  may, 
however,  be  possible  to  have  a  submittal  that  requires  multiple  files,  some 
of  which  are  approved  and  some  of  which  are  not  approved.  In  this  case, 
the  requirement  to  resubmit  specific  files,  and  not  the  entire  package, 
needs  to  be  modeled.  The  data  requirement  for  capturing  the  submittal 
evaluation  status  is  shown  in  Table  4-11. 
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Table  4-11.  Submittal  Action  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

RegisterltemID 

String 

Readonly 

Project-specific  ID 

RegisterActionTransmittallD 

Reference 

Readonly 

Reference  TransmittallD 

Regi  ste  rActi  0  n  Pe  rso  n  1 D 

Reference 

Readonly 

Reference  to  PersonID 

RegisterActionOn 

Date 

Reqd. 

Date  submitted 

RegisterActionType 

Referece 

Reqd. 

List  of  available  actions 

RegisterActionIsDeviation 

Boolean 

Reqd. 

Contains  deviation 

RegisterActionNote 

Memo 

Opt. 

Required  if  deviation 

Direct  action  on  a  given  submittal  should  triggers  the  designated  stats  on 
the  latest  version  of  all  associated  documents.  Similar  action  on  the  latest 
version  all  associated  documents  may  provide  the  owner’s  representative 
or  construction  manager  with  the  option  of  approving  the  entire  submittal 
Resolving  the  status  on  all  documents,  however,  does  not  automatically 
impart  the  same  status  to  the  over-arching  submittal  since  there  may  be 
documents  yet  to  be  transmitted. 

Evaluate  transmittal 

Evaluation  of  each  transmittal  may  be  made  individually.  Once  each  indi¬ 
vidual  transmittal  has  been  reviewed,  then  the  overall  submittal  may  have 
action  taken  on  it.  The  list  of  possible  actions  allowed  is  contingent  on  the 
type  of  the  overall  submittal.  The  data  fields  needed  to  track  actions  on  in¬ 
dividual  submittals  are  shown  in  Table  4-12. 


Table  4-12.  Transmittal  Action  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

TransmittalActionID 

String 

Readonly 

Action-specific  ID 

TransmittalActionRegisterlD 

Reference 

Readonly 

Ref.  to  Register  Item  ID 

TransmittalActionTransmittallD 

Reference 

Readonly 

Ref.  to  Transmittal  Item  ID 

TransmittalActionPersonID 

Reference 

Readonly 

Ref.  to  Person  ID 

TransmittalActionType 

Reference 

Reqd. 

List  of  possible  actions. 

TransmittalActionReqResubmit 

Boolean 

Reqd. 

Resubmission  required 

TransmittalActionIsDeviation 

Boolean 

Reqd. 

Action  contains  deviation 

TransmittalActionOn 

Date 

Reqd. 

Date  of  action 

TransmittalActionNote 

Memo 

Opt/Reqd. 

Required  if  deviation 

Once  all  transmittals  have  been  reviewed,  and  appropriate  action  taken, 
then  action  may  be  taken  on  the  overall  submittal.  Any  action  other  than 
“receipt  acknowledge,”  “approved,”  or  “approved  w/deviation”  on  all 
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transmittals  would  disable  the  options  to  approve  the  entire  submittal. 
Having  all  positive  transmittal  actions,  however,  does  not  ensure  that  all 
transmittals  have  been  made  against  the  submittal  requirement.  Therefore 
automated  approval  of  submittals  should  not  be  allowed  based  on  the 
status  of  individual  transmittals.  The  data  required  to  represent  the  sub¬ 
mittal  approval  is  shown  in  Table  4-13. 


Table  4-13.  Register  Action  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

RegisterActionID 

String 

ReadOniy 

Action-specific  ID 

RegisterActionRegisterlD 

Reference 

ReadOniy 

Ref.  to  Register  Item  ID 

Regi  ste  rActi  on  Pe  rso  n  1 D 

Reference 

ReadOniy 

Ref.  to  Person  ID 

RegisterActionType 

Reference 

Reqd. 

List  of  possibie  actions. 

RegisterAction  Req  Resu  bm  it 

Booiean 

Reqd. 

Resubmission  required 

RegisterActionIsDeviation 

Booiean 

Reqd. 

Action  contains  deviation 

RegisterActionOn 

Date 

Reqd. 

Date  of  action 

RegisterActionNote 

Memo 

Opt/Reqd. 

Required  if  deviation 

There  are  times  when  the  submittal  can  be  reviewed  and  action  taken  as  a 
whole.  In  this  case  the  action  taken  on  the  submittal  should  be  assigned  to 
each  of  the  individual  transmittals.  Implementations  of  this  condition 
would  simply  the  submittal  that  has  a  single  transmittal  (which  would  of¬ 
ten  be  the  case).  In  this  situation,  the  “approved”  event  on  the  submittal 
form  would,  for  example,  trigger  the  approval  of  the  individual  submittals 

Install  equipment 

Overview 

During  the  Install  Equipment  process,  information  related  to  each  piece  of 
material,  equipment,  and  product  are  provided  by  the  manufacturer  to  the 
subcontractor  or  contractor  (Figure  4-5).  This  information  includes  the 
as-installed  model  number,  specific  serial  number,  and  name  plate  data. 

In  addition,  the  location  where  each  individual  item  is  installed  will  be 
known  by  the  contractor  or  subcontractor.  Finally,  there  may  need  to  be  a 
certification  that  the  material,  product,  or  equipment  is  installed  in  accor¬ 
dance  with  the  manufacturer’s  instructions. 
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Subprocesses  within  scope 

Capturing  equipment  installation  information  during  construction  elimi¬ 
nates  the  need  to  perform  surveys  to  baseline  facility  information  models 
at  the  conclusion  of  a  project.  Adding  these  requirements  during  renova¬ 
tions  and  maintenance  activities  allows  building  models  to  be  aggregated 
during  operational  activities. 

Subprocesses  out  of  scope 

Support  for  the  contractor’s  supply  change  is  outside  the  scope  of  this 
process.  The  internal  procurement  systems  used  by  contractors,  subcon¬ 
tractors,  suppliers,  and  manufacturers  are  beyond  the  scope  of  COBIE. 

Eventually  the  information  to  be  provided  by  manufacturers  should  be  re¬ 
quired  to  be  provided  on  REID  tags.  Data  on  these  tags  would  provide 
electronic  nameplate  data.  Scanning  the  REID  tag  would  allow  the  auto¬ 
mated  capture  by  the  site  superintendent  with  minimal  interruption  by  the 
installer. 

Equipment  installation  data  requirement 

Extract  nameplate  data 

Ultimately  the  specific  attributes,  or  metadata,  for  each  material,  product, 
equipment,  or  system  component  installed  in  the  facility  should  have  its 
associated  data  set  provided  directly  by  the  manufacturer  with  the  elec¬ 
tronic  invoice.  Unfortunately  the  only  current  reliable  method  to  gather 
such  information  today  is  manual  survey.  In  COBIE  the  minimum  level  of 
information  about  each  piece  of  equipment  will  be  provided  based  on  a 
combination  of  a  general  header  data  set,  plus  specific  data  sets  for  prod¬ 
uct-dependant  attributes.  Table  4-14  provides  the  header  data  set  to  be 
collected  for  all  building  components  that  confer  a  warranty  to  the  owner. 


Table  4-14.  Generic  Installed  Component  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

InstalledItemID 

String 

ReadOniy 

Equipment-specific  ID 

InstalledItemRegisterD 

Reference 

ReadOniy 

Ref.  to  Register  Item  ID 

InstalledItemTransmittallD 

Reference 

Opt. 

Ref.  to  Transmittal  Item  ID 

InstalledItemModeINo 

String 

Opt. 

InstalledItemSeriaINo 

String 

Opt. 
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Information  from  the  prime  contractor  or  subcontractors,  suppliers,  and 
manufacturers  may,  eventually  be  added  to  this  standard  component  set. 
Such  information  based  on,  for  example,  barcode  (or  preferably  RFID)  tag 
information  might  include  the  manufacturing  date,  plant  and  run  number, 
shipping  information,  sensor  information  (such  as  if  the  unit  was 
dropped),  location  and  condition  of  equipment  during  intermediate  stor¬ 
age  locations.  Such  information  vital  to  manufacturers  for  the  tracking  of 
issues  related  to  warranty  defects  and  recalls,  is  currently  not  provided  by 
manufacturers  and,  therefore,  is  not  described  in  this  COBIE  specification. 

Space  model  information 

In  the  existing  OMSI  specification  data  related  to  the  location  of  installed 
equipment  and  product  placement  is  required  to  be  provided  based  on 
post-hoc  site  survey.  In  the  COBIE  specification  this  information  is  re¬ 
quired  to  be  completed  as  each  material,  equipment,  product,  or  system  is 
installed. 

Equipment  data  installation  in  OMSI  requires  that  the  room  number  be 
linked  to  the  specific  serial  number  of  the  equipment  that  is  installed  in 
the  room.  In  order  to  create  the  linkage  between  the  physical  building 
spaces  (inside  and  outside  the  facility)  and  the  installed  equipment,  spa¬ 
tially-related  data  about  the  building  configuration  should  be  initially  pro¬ 
vided.  Such  information  ultimately  may  be  provided  by  the  designer  dur¬ 
ing  the  preliminary  design  stage,  but  in  the  early  phases  of  COBIE 
implementation,  that  information  will  have  to  be  provided  by  the  prime 
contractor.  The  data  tables  required  to  link  together  the  installed  equip¬ 
ment  back  to  the  original  submittal  are  shown  below. 

Building  data  requirement  should  include  geospatial  reference  to  ensure 
that  information  provided  by  COBIE  can  be  tracked  against  external  data 
sources.  The  specific  format  for  the  location  will  be  determined  by  the  user 
group. 


Table  4-15.  Facility  Horizontal  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

FacilitylD 

String 

Readonly 

Building/Facility  specific  ID 

FacilityLocation 

Complex 

Opt. 

Format  to  be  determined 

FacilityName 

String 

Required 

Name  of  the  facility 
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Table  4-15  identifies  the  facility  and  provided  the  information  needed  the 
horizontal  placement  of  the  facility  with  geographic  space.  Table  4-16 
identifies  the  “stories”  associated  with  the  vertical  placement  of  spaces 
within  the  facility.  As  with  the  “Facility Location”  information,  the  “Verti- 
calLevelLocation”  format  is  yet  to  be  determined. 


Table  4-16.  Facility  Vertical  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

VerticalLevellD 

String 

Readonly 

Storey  specific  ID 

Verti  ca  1  Level  Faci  1  ityl  D 

Reference 

Readonly 

Building/Facility  specific  ID 

VerticalLevelLocation 

Complex 

Opt. 

Format  to  be  determined 

VerticalLevelName 

String 

Required 

Name  of  the  story  or  level 

Vertical  Level  Height 

Number 

Opt. 

Distance  “slab  to  slab” 

Once  the  vertical  levels  with  the  building  have  been  identified,  then  the 
spaces  that  comprise  these  levels  may  be  identified.  The  attributes  identi¬ 
fied  in  Table  4-17  are  extracted  from  existing  OMSI  specifications  for  space 
definitions.  Information  needed  to  summarize  the  functional  capabilities 
of  the  facility  are  also  noted  in  the  table,  these  include  “SpaceFunctionID,” 
“SpaceUsableArea,”  and  “SpaceUsableHeight.” 


Table  4-17.  Space  Data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

SpacelD 

String 

Readonly 

Space  specific  ID 

SpaceLevellD 

Reference 

Readonly 

Building/Facility  specific  ID 

SpaceFacilitylD 

Reference 

Readonly 

Story  specific  ID 

SpaceLocation 

Complex 

Opt. 

Format  to  be  determined 

SpaceNo 

String 

Opt./Reqd. 

Reqd.  if  a  building 

SpaceName 

String 

Required 

Name  of  the  space 

SpaceUsableArea 

Number 

Opt. 

Usable  floor  area 

SpaceUsableHeight 

Number 

Opt. 

Distance  "floor  to  ceiling” 

Note  that  the  definitions  of  “SpaceFunctionID,”  “SpaceUsableArea,”  and 
“SpaceUsableHeight”  should  be  evaluated  based  on  the  capability  of  exist¬ 
ing  software  systems,  such  as  BIM-based  CADD,  and  requirements  from 
real  estate  and  asset  management  standards. 


In  COBIE  the  specific  positioning  of  the  facilities,  vertical  levels,  and 
spaces  need  not  be  included  in  the  model.  Specific  owners  who  have  pre- 
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defined  formats  may,  however,  add  this  additional  requirement  to  their 
implementation  of  COBIE. 

Installed  equipment  location 

Given  a  definition  for  spaces  within  the  possible  multiple  facilities  and  ver¬ 
tical  levels  in  a  given  project,  it  is  possible  to  inventory  the  installed 
equipment  within  each  space.  The  exact  location  of  individual  items  with  a 
space  is  not  explicitly  required  in  COBIE.  Table  4-18  provides  the  required 
data. 


Table  4-18.  Installed  Equipment  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

InstalledItemID 

Reference 

Readonly 

Reference  to  Item  ID 

InstalledItemSpacelD 

Reference 

Readonly 

Reference  to  Space  ID 

InstalledItemPersonID 

Reference 

Readonly 

Reference  to  Person  ID 

InstalledItemOn 

Date 

Reqd. 

Date  item  was  installed 

InstalledItemPhoto 

Blob 

Reqd. 

Photos  of  installed  item 

InstalledItemDeviation 

Boolean 

Reqd. 

Is  installed  w/deviation? 

InstalledItemNeedCert. 

Boolean 

Reqd. 

Is  external  certification  needed 

InstalledItemNote 

Memo 

Opt/Reqd. 

Required  if  deviation 

Note  that  the  required  data  requires  that  digital  photos  of  each  equipment 
installation  be  taken  and  notations  of  deviations  from  manufacturer’s  in¬ 
stallation  instructions  be  identified.  It  may  be  possible  to  remove  the  “In- 
stalledltemNeedCert”  item  from  this  table  if  the  data  is  provided  else¬ 
where.  One  appropriate  location  for  this  information  is  to  identify  this 
requirement  in  the  initial  submittal  register. 

As-built  space  descriptions 

In  addition  to  the  equipment  inventory  required  for  COBIE,  product  de¬ 
scriptions  of  each  of  the  spaces  also  include  a  variety  of  additional  infor¬ 
mation  in  the  current  OMSI  specification.  The  objective  of  the  OMSI  in¬ 
formation  is  to  provide  an  asset  inventory,  therefore  the  COBIE 
specifications  will  conform  to  that  asset  management  requirement. 

Specific  as-built  descriptions  are  required  in  OMSI  for  the  products  in  the 
list  below  (see  Table  4-19).  These  items,  or  additional  items,  may  be  in¬ 
cluded  in  an  implementation  of  the  COBIE  specification  through  the 
“SpaceComponentType”  data  field: 


ERDC/CERLTR-07-30 


94 


•  Ceilings 

•  Doors 

•  Floor 

•  Lighting 

•  Plumbing 

•  Valves 

•  Windows. 

Two  OMSI  data  files  associated  with  electrical  fixtures  are  not  included  in 
the  as-built  space  data  requirement.  This  data  “Lighting  Fixture  Lamp 
Count”  and  “Watts  per  Lamp”  are  not  included  because  this  information 
should  have  already  been  identified  by  the  referenced  submittal. 


Table  4-19.  As-Built  Space  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

SpacelD 

Reference 

ReadOniy 

Reference  to  Space  ID 

SpaceltemTypelD 

Reference 

ReadOniy 

Reference  to  Type  ID 

SpaceltemRegiserlD 

Reference 

ReadOniy 

Reference  to  Submittal  ID 

SpaceltemCount 

Number 

Reqd. 

Number  of  components 

SpaceltemColor 

String 

Opt. 

Color  of  component 

SpaceltemDirection 

String 

Opt. 

Direction  of  action  (e.g.,  door) 

SpaceltemSystem 

String 

Opt. 

Name  of  component’s  system 

SpaceltemTagNo 

String 

Opt. 

SpaceltemPosition 

String 

Opt. 

SpaceltemNote 

Memo 

Opt. 

Future  COBIE  specifications  should  more  explicitly  require  the  exchange 
of  a  building  information  model,  rather  than  simply  an  asset  inventory. 
Such  requirements  will,  most  likely,  not  be  placed  on  construction  con¬ 
tractors,  however,  since  the  information  should  already  exist  in  “sche¬ 
matic”  and  “construction  document”  phases  of  design. 

Installation  certification 

Certification  of  some  types  of  equipment  is  needed  to  ensure  that  warran¬ 
ties  can  be  enforced.  Equipment  of  this  type  must  have  a  certification  that 
the  equipment  or  product  was  installed  according  to  manufacturer’s  in¬ 
structions.  The  specific  requirement  for  installation  certificates  should 
have  been  identified  in  the  submittal  register.  If  this  is  the  case,  then  the 
transmittal  documents  provided  with  the  submittal  will  meet  this  re¬ 
quirement. 
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Other  than  the  certification  submittal  associated  with  a  given  requirement, 
COBIE  will  not  address  the  specifics  of  the  certification.  For  example,  if  a 
certification  provided  for  a  single  installation  of  a  single  piece  of  equip¬ 
ment  the  current  representation  may  be  adequate.  If,  however,  a  certifica¬ 
tion  is  needed  for  multiple  equipment  installations,  it  is  not  clear  that  the 
specific  requirement  for  individual  or  multiple  certifications  can  be  ade¬ 
quately  addressed  with  COBIE,  at  this  time. 

Submit  test  results 

In  this  information  exchange,  test  results  are  provided  from  the  testing  or¬ 
ganization,  whoever  may  be  performing  the  test,  in  a  “document”  format 
and  provided,  as  identified  in  the  submittal  register  as  individual  submit¬ 
tals  (Table  4-20).  To  represent  situations  where  test  results  apply  to  mul¬ 
tiple  submittals,  for  example  HVAC  equipment.  The  test  submittal  must 
also  be  linked  into  the  specific  equipment  covered  by  the  test. 


Table  4-20.  Test  Results  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

TestID 

String 

Readonly 

Unique  test  ID 

TestRegisterReportID 

Reference 

Readonly 

Reference  to  test  report  ID 

TestRegisterltemID 

Reference 

Readonly 

Reference  to  subject  of  test  ID 

TestItemNote 

Memo 

Opt. 

AddI  note  if  needed 

Owner/Other 


_ _ 

^16  Verify  Inslallalioi^ 


Jl 

i.17  Subnnit  Certification 


:ificatiof^ 


CM/Owner’s  Rep 


Certification  by  owner  organizations  may,  or 
may  not  be  required,  and  could  provided  here  or 
during  commissioning. 


(i 


.20  Verify  Cert  &  Data 


21  Accept  Cert  &  Data 


Installed 

Equipment 


Prime  Contractor 


1 


Procured 

Eqijpmenr 


1  Purchased  Equipment 


i.2  Receive  Equipment 


3  Install  Equipment 


(j: 


.4  Extract  Nameplate  Data 


$ 


9 


6  Extract  Location  Data 


i  14  Certify  Installation 


Subcontractor 


1 


Procured 

Equipment 


5.7  Purchased  Equipment 


*) 


5.8  Receive  Equipment 


5) 


$ 


9  Install  Equipn>ent 


fs  10  Extract  Nameplate  Dat^^ 


19  Submit  Cert  &  Data 


1 1  Extract  Location  Data 


5) 


Certify  Installation 


5.18  Submit  Cert  &  Data 


5) 


This  process  includes  Contractor 
installed  Owner-Furnished  Equipment. 


Manufacturer 


_ 

This  process  captures: 
equivalent)  (2)  as-built 
(3)  if  specified,  external 

(1)  nameplate  data  (or 
ocaUon(s)  of  each  Item 
certification  documents. 

If  used  for  exisUng  equipment,  UID's  should  be 
provided  been  provided  by  the  facility  operator. 

_ 1 _ 

If  BIM  provided  upstrec 
will  already  be  known 
equipment  &  only  enter 
* - 

im,  equipment  locabon 
-  contractor  will  select 
make,  model,  serial  no. 

!  Verify  Installation 


1 3  Submit  Certification 


Certification  by  manufactures  rep.  may,  or  may 
not  be  required,  and  could  provided  here  or 
during  commissioning. 

I 

Construction  Managers  may  want  to  include 
contract  language  stating  that  payment  will  not 
be  provided  for  installation  until  the  data  (and 
certificabons)  are  provided. 


Figure  4-5.  Install  Equipment  process  chart. 


(O 

0) 
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Commission  equipment/systems 

Overview 

Following  the  installation  of  building  components  and  their  respective  sys¬ 
tems  the  commissioning  process  ensures  that  the  components  and  systems 
are  functioning  in  accordance  with  their  overall  performance  requirements 
as  defined  in  the  contract,  code,  or  standard  (Figure  4-6).  Three  types  of 
information  are  generated  as  a  result  of  the  commissioning  activity:  (1) 
test  results,  (2)  preventative  maintenance  instructions,  and  (3)  operational 
instructions.  The  capture  of  each  of  these  types  of  data  may  be  accom¬ 
plished  through  COBIE. 

The  format  for  preventative  maintenance  schedules  and  operational  in¬ 
structions  from  the  OMSI  standard  were  documented  in  an  ArchiBusFM 
review  of  OMSI.  Review  of  this  business  process  will  determine  if  the 
schedule  and  instructions  information  should  be  provided  in  consolidated 
PDF  format  or  in  computable  format  as  part  of  COBIEi  or  COBIE2. 

Subprocesses  within  scope 

To  be  determined. 

Subprocesses  out-of-scope 

To  be  determined. 

Commissioning  data  exchange  requirements 

Submit  operations  and  maintenance  manuais 

Eor  the  most  part  COBIE  considers  O&M  manuals  electronic  equivalents 
of  current  document  formats.  As  such,  these  submittals  are  currently 
called  out  in  the  register  and  provided  as  individual  transmittal  documents 
per  those  requirements.  There  are,  however,  two  types  of  information  that 
are  currently  required  by  the  OMSI  specification  that  may  be  captured  us¬ 
ing  the  COBIE  specification.  These  requirements  are  preventative  mainte¬ 
nance  instructions  and  minimum  equipment  training  requirements. 


Table  4-21.  Maintenance  Schedule  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

PMSchedulelD 

String 

Readonly 

Unique  schedule  ID 

PMScheduleRegisterltemID 

Reference 

Readonly 

Reference  to  subject  of  test  ID 

PMScheduleNote 

Memo 

Opt. 

AddI  note  if  needed 

(O 

00 


Figure  4-6.  Commission  Equipment  process  chart. 
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For  a  given  PM  schedule  there  will  be  specific  items  that  must  be  com¬ 
pleted  to  accomplish  the  work.  While  references  to  manufacturer  web  sites 
might  be  appropriate,  it  is  unlikely  that  owners  will  be  able  to  control  the 
specific  content  of  manufacturers’  sites  in  the  future.  As  a  resulted,  copies 
of  externally  referenced  materials  identified  in  a  checklist  item  should  be 
included  as  separate  uploaded  files  with  that  item.  The  set  of  data  needed 
to  represent  the  schedule  are  shown  in  Table  4-22. 


Table  4-22.  Maintenance  Schedule  Item  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

ScheduleltemID 

String 

ReadOniy 

Unique  test  ID 

SchedulelD 

Reference 

ReadOniy 

Reference  to  schedule  ID 

ScheduleltemOrder 

Number 

Reqd. 

Reference  to  subject  of  test  ID 

ScheduleltemNumber 

String 

Opt. 

Text  to  organize  display/print 

ScheduleltemDescription 

Memo 

Opt. 

Addl.  note  if  needed 

ScheduleltemReference 

Biob 

Opt. 

Addl.  Material  if  needed 

OMSI  specification  also  requires  that  the  training  courses  required  prior  to 
operation  or  maintenance  of  the  equipment  be  identified  for  the  facility 
manager.  In  the  OMSI  specification,  both  system-  and  equipment-level 
training  are  identified.  Without  a  definition  of  equipment  systems,  the  link 
between  training  requirements  and  equipment  systems  cannot  be  defined. 
As  a  result,  training  data  requirements  begin  with  the  definition  of  build¬ 
ing  systems  for  which  training  is  required.  Note  that  the  description  of 
testing  reports  and  certifications  may  also  require  the  definition  of  facility 
systems  as  well. 


Table  4-23.  System  Definition  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

System  ID 

String 

Readonly 

Unique  test  ID 

ScheduleltemDescription 

Memo 

Opt. 

Addl.  note  if  needed 

ScheduleltemReference 

Blob 

Opt. 

Addl.  Material  if  needed 

Table  4-24.  System  Component  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

ComponentRegisterltemID 

Reference 

Readonly 

Reference  to  subject  of  test  ID 

ComponentSystemID 

String 

Readonly 

Unique  test  ID 

ComponentItemOrder 

Number 

Reqd. 

Reference  to  subject  of  test  ID 

ComponentItemDescription 

Memo 

Opt. 

Addl.  note  if  needed 
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Now  that  the  systems  upon  which  training  are  required  have  been  defined, 
the  following  training  programs  and  individual  training  steps  can  be  iden¬ 
tified.  Note  that  an  additional  set  of  data  is  required.  That  set  of  data  links 
the  training  program  to  the  relevant  system  or  the  equipment  needed. 
Given  that  a  single  training  program  may  be  required  to  service  multiple 
equipment  this  data  requires  the  definition  of  a  many-to-many  relation¬ 
ship. 


Table  4-25.  Equipment/System  Training  Program  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

ProgramID 

String 

ReadOniy 

Unique  training  ID 

ProgramNumber 

String 

Opt. 

Text  to  organize  dispiay/print 

Progra  m  Description 

Memo 

Opt. 

Addi.  note  if  needed 

ProgramReference 

Biob 

Opt. 

Addi.  Materiai  if  needed 

Table  4-26.  Equipment/System  Training  Item  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

TrainingID 

String 

ReadOniy 

Unique  training  ID 

TrainingRegisterltemID 

Reference 

ReadOniy 

Reference  to  register  ID 

TrainingItemOrder 

Numbet 

Reqd. 

Reference  to  subject  of  test  ID 

TrainingItemNumber 

String 

Opt. 

Text  to  organize  dispiay/print 

TrainingItemDescription 

Memo 

Opt. 

Addi.  note  if  needed 

TrainingItemReference 

Biob 

Opt. 

Addi.  Materiai  if  needed 

Provide  warranty 

Overview 

Capture  of  warranty  information  is  one  of  the  first  major  requirements  for 
the  COBIE  project  (Figure  4-7).  There  are  three  types  of  information  that 
need  to  be  captured  with  regards  to  warranty.  The  first  of  these  three  types 
of  information  is  to  what  the  warranty  applies.  The  second  are  the  terms  of 
the  warranty  and  certificate.  The  third  is  information  identifying  the  guar¬ 
antor  of  the  warranty. 

Subprocesses  within  scope 

Generic  metadata  defining  the  duration  and  scope  of  the  warranties  are 
included  in  the  COBIE  initial  specification.  This  metadata  also  include  the 
contact  information  for  the  warrantor  and  specifically  link  the  warranty 
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metadata  to  the  precise  materials,  products,  and  equipment  to  which  the 
warranty  applies. 

Subprocesses  out-of-scope 

To  be  determined 

Warranty  exchange  requirements 

Terms  and  certificate 

The  “WarrantyCertificate”  is  a  PDF  facsimile  of  the  signed  warranty  cer¬ 
tificate  provided  by  the  manufacturer.  Data  related  to  the  “ Warranty Star- 
tOn”  and  “WarrantyEndOn”  dates  must  also  be  provided  with  the  “War- 
rantylD”  record  (see  Table  4-27).  COBIE  is  not  prescriptive  of  the 
definitions  or  implication  of  the  dates  of  the  warranty  based  on  installation 
or  occupancy.  Such  information  should,  however,  be  clarified  since  manu¬ 
facturers’  warranties  typically  begin  on  the  date  of  installation. 


Table  4-27.  Warranty  Terms  and  Certificate  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

Warranty  ID 

String 

ReadOniy 

Unique  warranty  ID 

WarrantyStartOn 

Date 

Reqd. 

Start  date  of  warranty 

WarrantyEndOn 

Date 

Reqd. 

End  date  of  warranty 

WarrantyCertificate 

Biob 

Reqd. 

Copy  of  certificate 

Appiicabiiity 

Identification  of  the  equipment  covered  by  the  warranty  is  provided 
through  a  linking  table  that  identifies  the  warranty  and  each  individual 
piece  of  equipment  to  which  the  warranty  applies  (Table  4-28).  Typically 
warranties  will  be  assigned  against  the  general  submittal  item.  In  COBIE  a 
separate  submittal  will  be  required  to  model  situations  where  different 
equipment  of  the  same  type  applies  to  different  warranties.  Table  4-28 
shows  the  linking  between  the  warranty  item  and  the  warranty. 


Table  4-28.  Warranty  Applicability  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

AppiicabiiityWarrantylD 

Reference 

ReadOniy 

Reference  to  warranty  ID 

AppiicabiiityRegisterltemID 

Reference 

ReadOniy 

Reference  to  subject  of  test  ID 
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Guarantor 

Designation  of  the  Guarantor  is  simply  the  linking  between  the  specific 
warranty  and  the  responsible  organization  (Table  4-29). 


Table  4-29.  Warranty  Guarantor  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

GuarantorWarrantylD 

Reference 

Readonly 

Reference  to  warranty  ID 

GuarantorOfficelD 

Reference 

Readonly 

Reference  to  office  ID 

CM/Owner's  Rep  Prime  Contractor  Subcontractor 


Manufacturer 


ConiinaBonod 

Equipmenl 


CorrvTHxxionnil 

Eqtiprnert 


7.1  Request  Wafranty 


lte«ns  that  require  warranties  are  Identified  in  the  submittal  log  but 
should  not  be  accepted  until  equipment  has  been  accepted  during 
the  commissioning  as  part  of  an  operational  system.  Defining  the 
actual  warranty  start  date  is  outside  the  scope  of  the  C06IE 


WiMTamed 

ManeriaJs, 

PrOdLKlS. 

Equvimerr 


This  chart  does  not  consider  updates  or  changes  needed  to 
existing  or  previously  provided  warranty  data.  Such  activities  are 
part  of  this  process,  but  not  deschbed  in  this  chart. 


Figure  4-7.  Provide  Warranty  process  chart. 
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Provide  spare  and  replacement  parts  sources 

Overview 

There  are  three  key  types  of  data  to  capture  and  exchange  related  to  spare 
and  replacement  parts  information  (see  Figure  4-8).  One  is  the  identifica¬ 
tion  of  the  parts  list  with  appropriate  manufacturer  (or  supplier)  stock 
numbers.  The  second  is  the  applicability  of  the  parts  to  specific  products 
and  equipment.  The  third  is  the  list  of  suppliers  who  are  able  to  provide 
the  needed  set  of  replacement  parts  if  one  of  the  spares  on  hand  has  been 
used.  These  data  requirements  are  identified  in  the  sections  below. 

Subprocesses  within  scope 

Generic  metadata  defining  the  names  of  parts,  their  item  numbers  and 
suppliers  are  included  in  the  initial  COBIE  standard.  This  metadata  also 
links  the  spare  parts  and  supplier  to  the  precise  materials,  products,  and 
equipment  to  which  they  apply. 

Subprocesses  out-of-scope 

To  be  determined 


Exchange  requirements 

Parts  sets 

The  identification  of  a  set  of  parts  may  contain  a  specific  parts  list  and/or  a 
diagram  showing  where  the  parts  are  located.  The  Spare  Parts  Set  data  re¬ 
quirement  allows  the  capture  of  diagrammatic  representations  of  the  spare 
parts  list.  The  Spare  Parts  List  requirement  identifies  the  list  of  parts  that 
could  be  provided  in  a  table.  Such  information  is  preferred,  in  the  long 
term,  since  request  for  quotes  from  suppliers  could  be  automatically  gen¬ 
erated  from  the  combination  of  data  found  in  Table  4-30  -  Table  4-32. 


Name 

PartsSetID 

PartsSetDescription 

PartsSetOrder 


Table  4-30.  Spare  Parts  Set  data  requirement. 


Type 


Reqd/Opt 


Description 


String 


Readonly 


Unique  ID  for  part  set  ID 


String 


Reqd. 


Description  of  the  parts  set 


String 


Opt. 


Order  used  for  display 


Opt. 


Any  needed  addl.  information 


PartsSetNote 


Memo 
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Table  4-31.  Spare  Parts  Set  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

PartsListDocSetID 

Reference 

Readonly 

Reference  to  part  set  ID 

PartsListDocDescription 

String 

Reqd. 

Part  name 

PartsListDocFile 

Blob 

Reqd. 

Copy  of  associated  documents 

PartsListDocOrder 

String 

Opt. 

Order  used  for  display 

Table  4-32.  Spare  Parts  List  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

PartsListID 

String 

Readonly 

Unique  ID  for  part  ID 

PartsListSetID 

Reference 

Readonly 

Reference  to  part  set  ID 

PartsListDescription 

String 

Reqd. 

Part  name 

PartsListNumber 

String 

Reqd. 

Part  number 

PartsListOrder 

String 

Opt. 

Order  used  for  display 

PartsListNote 

Memo 

Opt. 

Any  needed  addl.  information 

PartsListDocumet 

Blob 

Opt. 

Copy  of  associated  documents 

Applicability 

Identification  of  the  equipment  covered  by  a  given  parts  list  is  provided 
through  a  linking  table  that  identifies  the  parts  set  and  the  class  of  equip¬ 
ment  to  which  the  warranty  applies.  Typically  warranties  will  be  assigned 
against  the  general  submittal  item.  In  COBIE  a  separate  submittal  will  be 
required  to  model  situations  where  different  equipment  of  the  same  type 
applies  to  different  warranties.  Table  4-33  shows  the  linking  between  the 
warranty  item  and  the  warranty. 


Table  4-33.  Part  Set  Applicability  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

ApplicabilityPartSetID 

Reference 

Readonly 

Reference  to  warranty  ID 

ApplicabilityRegisterltemID 

Reference 

Readonly 

Reference  to  subject  of  test  ID 

Sources 

Spare  parts  sources  are  described  by  a  linking  table  that  joins  the  parts  set 
with  one  (or  more)  suppliers  who  could  provide  the  parts  (Table  4-34). 
Given  the  identification  of  the  parts  from  the  previous  lists  and  contact  in¬ 
formation  available  through  the  linked  data  in  this  table  COBIE  could  pro¬ 
vide  direct  services  to  support  facility  managers’  supply  parts  procurement 
process. 
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Table  4-34.  Spare  Parts  Sources  data  requirement. 


Name 

Type 

Reqd/Opt 

Description 

GuarantorPartsSetID 

Reference 

Readonly 

Reference  to  warranty  ID 

GuarantorOfficelD 

Reference 

Readonly 

Reference  to  office  ID 

Figure  4-8.  Provide  Spare  Parts  Sources  process  chart. 
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Transmit  handover  information 

All  of  the  previous  data  requirements  are  pulled  together  during  the  steps 
under  this  process  (see  Figure  4-9).  In  COBIE,  the  data  provided  to  facil¬ 
ity  managers  will  include  the  information  from  the  contractor’s  supply 
chain  captured  during  the  constructor’s  quality  control  and  owner’s  repre¬ 
sentative  or  construction  manager’s  quality  assurance  process.  Other  proc¬ 
esses  accomplished  by  other  parties  at  different  times  may,  in  the  future 
provide  additional  data,  or  allow  the  data  to  be  provided  prior  to  the 
COBIE  process.  An  example  of  such  information  would  be  the  provision  of 
a  space-oriented  building  model  within  which  material  and  equipment 
would  be  located.  If  such  information  were  provided  during  the  architec¬ 
tural  programming  and  schematic  design  phase,  then  the  construction 
contractor  need  only  to  identify  the  equipment  purchased  and  match  spe¬ 
cific  equipment  with  the  generic  identification  of  where  the  equipment  of 
that  type  was  to  be  placed. 

Eor  COBIE,  the  information  to  be  transferred  from  contractors  to  opera¬ 
tors  will  be,  primarily,  limited  to  material,  product,  and  equipment  specifi¬ 
cations  for  the  purposes  of  providing  unsupervised  data  loading  into  com¬ 
puterized  maintenance  management  systems.  The  specific  coding  if  this 
information  exchange  will  be  defined  in  ifcXML  format,  however,  the  data 
will  be  that  already  described  in  the  sections  above. 


Populated 

ChMS 


COBIE  July  2007  allows  designers  to  Identify  if 
submittals  are  for  items  that  represent  “fixed" 
or  “movable"  products^  equipment  This 
facilitates  counting  during  building  turn-over. 

COBIE  Jul  2007  requires  identification  of 
equipment  type  and  space  function  in 
accordance  with  the  OmnICIass 
categorization.  Owner's  will  need  to  map  their 
internal  taxonomies  to  the  OmniClass  scheme 
or  substitute  their  classification  schema. 


COBIE  Jul  2007  Includes  optional  data  for 
asset  management  functions.  Determining  the 
requirement  for  space  and  asset  management 
management  data  should  be  accomplished  by 
the  owner,  and  identified  in  the  design  and 
construction  contract. 


Figure  4-9.  Transmit  Handover  information  process  chart. 
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O&M  synchronization 

When  information  is  accepted  by  the  facility  operator,  this  information 
must  be  harmonized  with  information  that  already  exists  within  the  opera¬ 
tor’s  maintenance  management  systems.  It  is  vital  that  information  about 
existing  facilities  or  repair  efforts  to  existing  equipment  be  correctly  up¬ 
dated  with  new  COBIE  data  otherwise  building  information  model  data 
will  not  be  able  to  grow  over  time  to  reflect  as-built  conditions.  COBIE  will 
address  the  requirements  for  new  facilities,  or  new  portions  of  existing  fa¬ 
cilities  only. 

The  use  case  supported  from  this  process  will  be  to  allow  the  contractor  to 
receive  the  data  associated  with  the  building  spatial  inventory  prior  to  the 
start  of  construction.  If  this  information  is  available,  then  contractor  per¬ 
sonnel  will  not  need  to  recreate  it.  Data  requirements  for  this  exchange 
were  discussed  previously. 
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5  COBIE  Pilot  Implementation  Standard 

Implementation  overview 

The  COBIE  Pilot  Implementation  standard  supports  all  the  information 
exchange  requirements  that  modify  and  finalize  information  eventually 
provided  to  facility  operators  by  the  construction  contractor.  As  a  result, 
users  of  the  COBIE  spreadsheet  will  need  to  consider  which  of  these  proc¬ 
esses  will  need  to  be  included  in  design  and  construction  contract.  Legacy 
software  systems  may  also  support  some,  or  all,  of  the  data  exchange  re¬ 
quirements  identified  by  COBIE. 

In  many  cases  users  of  the  COBIE  data  standard  should  be  unaware  that 
their  software  system  is  capturing  data  for  COBIE.  If,  however,  users  are 
required  to  enter  data  into  the  COBIE  spreadsheet  directly,  the  COBIE 
data  should  be  loaded  in  order  of  the  processes  that  created  the  data.  This 
process  is  directly  reflected  in  the  order  of  the  worksheets.  Groups  of 
worksheets  reference  data  created  during  design,  procurement,  installa¬ 
tion,  and  commissioning  processes.  Loading  the  COBIE  data  in  order  from 
first  to  last  worksheet  will  simplify  the  tracking  of  information  about  the 
facility  that  is  required  to  be  linked  across  multiple  worksheets. 

While  replacing  paper  documents  with  COBIE  formatted  data  is  expected 
to  reduce  the  cost  of  the  production  and  use  of  COBIE  data,  a  more  holistic 
approach  would  be  to  require  the  capture  of  COBIE  data  throughout  the 
project  development.  The  use  of  commercial  software  systems  for  this 
purpose  is  recommended.  It  is  possible,  if  commercial  software  systems 
are  not  in  place,  to  manage  such  data  directly  through  the  COBIE  spread¬ 
sheet.  Development  of  contract  language  to  support  such  exchanges  will 
need  to  be  crafted  based  on  the  specifics  of  the  parties  and  required  ex¬ 
changes.  Eor  generic  examples  of  contract  language,  see  Chapter  8. 

Introduction  to  the  COBIE  spreadsheet 

COBIE  has  been  designed  based  on  an  extensive  review  of  literature,  re¬ 
lated  past  projects,  and  expert  consultations.  COBIE  reflects  a  compromise 
among  the  following  constraints:  (i)  data  structures,  entities,  and  property 
sets  provided  by  lEC  2x3;  (2)  organization  of  information  that  reflects  the 
‘natural’  way  practitioners  use  COBIE  data;  and  alternative  means  of  rep¬ 
resenting  object-oriented  data  in  the  relational  format  provided  by  a 
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spreadsheet.  A  report  on  these  activities  is  in  preparation  for  publication 
in  December  2007. 

Several  of  the  key  design  decisions  made  during  the  creation  of  the  spread¬ 
sheet  format  are  described  in  the  following  paragraphs.  This  information 
will  be  of  interest  to  both  software  vendors  and  users  of  the  COBIE 
spreadsheet. 

Process-based  representation 

There  are  many  ways  to  represent  data,  the  most  commonly  used  repre¬ 
sentation  of  data  today  is  based  on  so-called  normalized  relational- 
database  tables.  The  IFC  model  uses  an  object-oriented  format  for  its  rep¬ 
resentation  of  BIM  data.  COBIE  data  in  the  Pilot  Implementation  Stan¬ 
dard  is  primarily  represented  by  the  order  in  which  the  data  is  created  dur¬ 
ing  the  life-cycle  of  the  project.  The  relational-database  information  is 
provided  in  the  Pilot  Implementation  Standard,  using  foreign  keys  and 
lookup  lists,  however,  process-orientation  is  the  primary  motivating  factor 
for  the  COBIE  Pilot  Implementation  Standard. 

There  are  at  least  two  implications  of  the  process-based  representation  of 
the  COBIE  data  found  in  the  Pilot  Implementation  Standard.  The  first  is 
for  end  users  of  the  spreadsheet.  Users  that  need  to  directly  add  data  to  the 
spreadsheet  may  go  directly  to  those  tables  for  which  they  are  responsible 
and  only  add  the  data  that  they  create.  For  example,  in  the  list  of  spaces 
(rooms),  the  designer  provides  the  room  number  and  associated  special 
measurements;  having  the  contractor  re-create  that  information  at  the  end 
of  construction  duplicates  work  and  may  introduce  errors. 

The  second  implication  of  the  process-based  representation  is  that  soft¬ 
ware  implementers  will  need  to  look  across  multiple  worksheets  to  find 
information  that  they  would  often  include  in  a  single  table.  For  example, 
the  designer  specifies  that  Fan  Coil  Unit  01  is  located  in  room  101.  Later 
the  contractor  who  installs  the  equipment  provides  the  serial  number  for 
that  equipment.  Since  the  data  is  created  at  different  times  during  the  pro¬ 
ject,  in  the  COBIE  Pilot  Implementation  Standard,  the  data  is  provided  on 
different  worksheets.  While  the  software  issues  around  these  issues  are 
easily  solved,  it  is  important  to  understand  this  process-orientation  prior 
to  starting  work  on  COBIE  import/export  modules. 
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Internal  referencing 

COBIE  data  are  interrelated.  This  is  key  difficulty  in  capturing  and  track¬ 
ing  this  data.  To  manage  the  relationships  between  data  in  the  COBIE 
spreadsheet  each  row  in  a  given  worksheet  is  sequentially  numbered.  This 
Locally  Unique  Identifier  (LUID)  serves  as  the  unique  internal  reference 
number  for  information  on  the  spreadsheet.  This  number  may  be  refer¬ 
enced,  as  in  the  case  of  a  “foreign  key,”  on  other  worksheets.  The  number 
may  also  be  referenced  on  the  same  worksheet  to  identify  aggregation  or 
sequential  relationships. 

The  relational  nature  of  information  in  COBIE  is  easily  supported  by 
commercial  automated  systems  that  maintain  relational  database  linkage 
using  business  rules.  Some  users  providing  information  directly  into  the 
COBIE  spreadsheet  may  experience  difficulty  since  index  values  between 
tables  must  be  manually  selected.  The  COBIE  spreadsheet  is  not  meant  as 
an  alternative  to  commercial  software,  simply  as  a  simple  implementation 
standard  of  the  COBIE  exchange  requirement. 

There  are  two  types  of  internal  referencing  in  the  COBIE  Pilot  Implemen¬ 
tation  Standard  and  found  in  the  COBIE  spreadsheet.  The  first  is  a  compo¬ 
sitional  reference.  This  reference  corresponds  to  the  one-to-many  rela¬ 
tional  database  construct.  In  the  table  that  contains  the  “many,”  a  link  to 
“one”  item  from  that,  or  another,  worksheet  will  be  provided.  These  com¬ 
positional  references  can  be  found  throughout  COBIE.  Eor  example:  for  a 
given  building,  there  may  be  one  or  more  floors;  for  a  given  floor,  there 
may  be  several  spaces;  for  a  given  system,  there  may  be  a  set  of  equipment. 
To  simplify  the  end-user’s  interaction  with  the  spreadsheet,  a  calculated 
field  has  been  added  to  the  sample  spreadsheet.  This  calculated  field  pro¬ 
vides  a  lookup  list  on  the  “many”  table  including  both  the  LUID  number  of 
the  referenced  data  but  also  the  name  of  that  data.  In  processing  the  link 
that  contains  the  calculated  data  only  the  first  numeric  value  (correspond¬ 
ing  to  the  foreign  key  value)  should  be  used. 

The  other  type  of  internal  referencing  in  the  COBIE  Pilot  Implementation 
Standard  is  that  of  many-to-many  relational  link.  In  this  situation,  the  In¬ 
teger  List  data  type  is  provided.  In  the  Integer  List  data  type  (e.g., 
SpacelDList,  DocumentIDList,  etc.),  a  comma-delimited  list  of  the  ID 
numbers  from  the  designated  worksheet,  will  be  provided.  The  integer  list 
data  fields  that  are  required  shall  have  one  or  more  values  identified. 
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External  referencing 

COBIE  data  is  also  related  to  information  outside  the  specific  instance  of  a 
given  COBIE  spreadsheet.  Optional  fields  are  provided  in  the  COBIE 
spreadsheet  to  allow  parties  to  include  references  to  data  systems  beyond 
the  scope  of  the  COBIE  data.  Requirements  for  the  specification  of  such 
external  references  are  up  to  specific  implementations  developed  for  spe¬ 
cific  project  teams  or  settings. 

One  example  of  such  an  external  reference  would  occur  when  an  owner 
has  an  accounting  system  that  contains  a  property  identifier.  If,  for  exam¬ 
ple,  an  owner  has  a  unique  identifier  for  each  facility  that  is  managed  and 
tracked  in  a  corporate  database,  then  that  owner  can  require  those  provid¬ 
ing  COBIE  data  to  list  that  external  identifier  within  the  needed  external 
reference  fields. 

Tracking  authorship 

All  data  in  COBIE  is  identified  against  the  person  who  provided  or  created 
the  data.  The  first  worksheet  in  the  COBIE  spreadsheet  identifies  the  list  of 
all  persons  and  firms  referenced  in  all  later  sheets.  Each  record  of  COBIE 
data  in  all  sheets  refers  back  to  the  ID  numbers  of  those  users  listed  in  the 
first  worksheet.  In  addition  to  identifying  who  was  responsible  for  provid¬ 
ing  or  creating  the  COBIE  data,  the  date  and  time  that  the  data  was  en¬ 
tered  is  noted. 

Ownership  decomposition 

Decomposition  of  data  in  the  COBIE  spreadsheet  reflects  the  process  of 
data  ownership.  Eor  example,  the  name  “AHU-i”  name  is  tagged  to  spe¬ 
cific  piece  of  equipment  in  a  given  location  during  design.  The  serial  num¬ 
ber  for  “AHU-i”  is  provided  by  manufacturer  and  recorded  by  the  installer. 
Keeping  the  name  of  “AHU-i”  and  the  “serial  number”  in  the  same  COBIE 
record  makes  sense  from  a  data  modeling  efficiency  point  of  view  but  re¬ 
quires  field-based  data  locking  that  would  be  more  difficult  to  explicitly 
manage. 

In  the  COBIE  spreadsheet,  two  separate  records  are  provided  for  named 
equipment.  The  “Component”  table  identifies  all  named  equipment  or 
other  building  components  identified  during  the  design  process.  The  “In¬ 
stallation”  table  identifies  the  contractor  provided  attributes  of  installed 
equipment. 
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Change  history 

The  COBIE  spreadsheet  may,  depending  upon  its  implementation,  be  used 
to  exchange  information  about  the  history  of  changes  during  the  design  or 
construction  process.  The  “ReplacesID”  column  is  the  last  column  in  every 
worksheet  of  the  COBIE  spreadsheet.  The  use  of  data  in  this  column  is  to 
identify  the  earlier  row  of  data  on  the  same  worksheet  that  is  to  be  re¬ 
placed  by  the  current  row.  Once  included  in  a  COBIE  spreadsheet  records 
are  not  allowed  to  be  updated.  Replacement  rows  of  data  provide  the  re¬ 
cord  of  incremental  changes.  Comparison  of  COBIE  spreadsheets  between 
two  time  periods  (along  with  gaps  in  LUIDs)  identify  deleted  rows. 

Occasionally  some  data  elements  previously  provided  in  a  COBIE  informa¬ 
tion  exchange  may  need  to  be  identified  as  no  longer  being  active  data  —  if 
a  construction  change  order  combines  two  rooms  into  a  single  room,  for 
example.  Once  provided  in  the  spreadsheet,  the  data  cannot  be  removed. 
The  following  procedure  is  to  be  used  to  flag  data  that  is  “withdrawn”  from 
the  Building  Information  Model  represented  in  COBIE.  Eirst,  an  updated 
row  that  matches  the  most  recent  related  data  is  required  to  be  added  with 
the  user  ID,  date,  and  time  that  the  data  was  removed  from  the  BIM.  Sec¬ 
ond,  this  record  will  have  the  new  column,  “Withdrawn,”  set  to  “Yes.” 

The  current  data  set  is  that  set  of  records  across  all  worksheets  that  has 
not  been  superseded  or  withdrawn. 

Separation  of  value  and  units 

COBIE  is  based  upon  the  lEC  model  for  many  of  its  basic  data  type  mod¬ 
els.  One  of  these  models  in  lEC  identifies  the  value  of  an  item  separately 
from  the  units  associated  with  that  item.  Such  a  separation  is  reflected 
throughout  the  COBIE  specification  to  ensure  that  there  is  no  confusion 
about  units  of  measure  during  information  exchanges. 

Unless  otherwise  noted,  it  is  assumed  that  the  default  units  of  COBIE  will 
be  millimeters. 

Facility  management  practice 

Eacility  management  experts  specified  that  the  presentation  of  COBIE  data 
in  any  human-readable  format  needs  to  reflect  the  common  organization 
of  the  material  that  is  received  at  construction  handover.  Eor  example,  the 
records  for  “Manual”  and  “Instruction”  are  the  same  and  would  otherwise 
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be  merged  by  a  system  analysis  with  some  kind  of  category  designation 
field.  Facility  Managers,  however,  found  such  a  construction  more  difficult 
to  understand  than  simply  providing  two  separate  worksheets. 

In  previous  COBIE  drafts,  a  single  worksheet  for  task-related  information 
was  developed.  A  task  category  identified  the  nature  of  these  tasks.  Expert 
maintenance  personnel,  serving  on  the  COBIE  team,  explicitly  requested 
that  this  information  be  separated  into  the  individual  types  of  jobs  that 
needed  to  be  done.  Thus  there  are  now  task  lists  for  “PM,”  “Safety,” 
“Startup,”  “ShutDown”  etc... 

Progressive  implementation 

Today,  the  electronic  information  provided  by  manufacturers  in  a  non¬ 
document  format  is  limited.  Eor  example  exploded  diagrams  for  spare 
parts  lists  are  common.  In  other  cases,  job  plans  for  different  kinds  of 
work  are  listed,  again  in  documents.  The  COBIE  standard  is  able  to  accept 
these  documents,  but  will  also  accept  full  sets  of  data,  if  provided  by 
manufacturers. 

A  designer’s  maturity  with  BIM  technology  will  also  have  an  impact  upon 
the  data  provided  through  COBIE.  If  the  design  team  is  not  using  BIM, 
then  the  “Coordinates”  of  rooms  and  spaces,  relative  to  the  origin  point  of 
the  facility,  would  be  difficult  to  identify.  As  a  result,  in  the  COBIE  Pilot 
Implementation  standard  coordinates  are  listed  as  an  optional  worksheet. 
If  the  design  team  uses  BIM-based  software,  then  the  production  of  space 
and  equipment  coordinates  would  simply  be  an  export  from  the  BIM. 

Another  area  that  will  evolve  over  time,  and  is  currently  supported  by  the 
COBIE  Pilot  Implementation  standard,  is  property  sets.  Property  sets,  for 
example,  could  define  the  type  of  finish  to  be  installed  in  a  given  space  or 
the  performance  specifications  of  individual  materials  or  work  products. 
As  these  property  sets  become  standardized  through  the  additional  efforts 
of  the  NBIMS,  they  may  be  referenced  in  specific  implementations  of  the 
COBIE  standard. 

COBIE  pilot  implementation  spreadsheet 

Overview 

The  COBIE  Pilot  Implementation  standard  spreadsheet  is  organized  in 
seven  sets  of  worksheets.  These  worksheets  may  be  created  using  com- 
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monly  used  spreadsheet  tools,  through  translation  of  Building  Information 
Models,  or  commercial  database  or  management  systems.  The  value  of  the 
spreadsheet  format  is  that  the  ubiquitous  nature  of  the  spreadsheet  will 
allow  the  widest  possible  use  of  the  COBIE  standard  including  medium 
and  even  small  commercial  contractors. 

The  first  set  of  worksheets  needed  for  COBIE  is  the  single  contact  work¬ 
sheet  shown  in  Table  5-1.  The  contact  Worksheet  contains  all  data  needed 
for  the  capture  of  both  data  ownership  and  company  references.  The  ID 
number  of  the  individuals  and  firms  listed  in  the  Contact  worksheet  is 
used  as  a  reference  in  through  all  later  worksheets. 


Table  5-1.  Contact  worksheet. 


Worksheet 

Purpose 

Author 

01 

Contact 

People/offices/companies  referenced  in  this  fiie. 

Aii 

At  the  start  of  a  project  the  function  and  layout  of  horizontal  and  vertical 
spaces  within  a  facility  are  defined.  The  design  worksheet  set.  Table  5-2, 
describes  the  design  features  required  by  facility  operators.  Today,  many 
contractors  are  required  to  recreate  this  information  even  though  it  is 
originally  created  by  the  designer.  In  COBIE,  the  designer  is  required  to 
provide  the  list  of  spaces  and  their  functions.  Construction  contractors  are 
required  to  add  records  to  these  tables  to  reflect  as-built  conditions. 


Table  5-2.  Design  worksheets. 


Worksheet 

Purpose 

Author 

02 

Faciiity 

Identification  of  faciiity(ies)  referenced  in  a  fiie 

Designer 

03 

Fioor 

Description  of  verticai  ieveis 

Designer 

04 

Space 

Spaces  referenced  in  a  project 

Designer 

05 

System 

Systems  referenced  in  a  project 

Designer 

06 

Register 

Materiai/equipmenl/etc.  cataiog  (submittai  register) 

Designer 

07 

Component 

Individuaiiy  named  materiais  and  equipment 

Designer 

08 

Attribute 

Materiai/equipment/etc.  properties 

Designer 

09 

Coordinate 

Location  of  spaces  and  components 

Designer 

Designers  also  select  the  performance  requirements  for  equipment,  com¬ 
ponents,  and  materials  to  be  installed.  The  catalogue  of  items  that  describe 
materials,  components,  and  equipment  to  be  submitted  by  the  construc¬ 
tion  contractor  is  the  “submittal  register.”  This  “Register”  is  provided  as  a 
COBIE  worksheet.  The  list  of  individually  named  equipment  is  found  in 
COBIE  under  the  “Component”  worksheet.  At  a  minimum  the  Component 
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worksheet  will  contain  the  list  of  all  individually  named  equipment,  and 
items  found  in  schedules  such  as  door  hardware. 

Designers  combine  individual  components  to  create  systems  providing 
services  within  buildings.  The  COBIE  worksheet  “System”  allows  the  de¬ 
signer  to  provide  the  list  of  systems.  Large  projects  will  include  multiple 
systems,  such  as  zones,  in  different  parts  of  a  facility.  The  “System”  work¬ 
sheet  enables  such  decisions  to  be  captured  by  the  designer  instead  of  hav¬ 
ing  to  be  recreated,  as  is  current  practice,  by  construction  contractors. 

The  next  set  of  worksheets  capture  the  interface  between  a  construction 
contractor’s  supply  chain  management  and  the  construction  manager’s 
quality  assurance  process.  During  this  process  documents  describing  the 
materials,  components,  equipment,  and  systems  to  be  installed  on  the  pro¬ 
ject  are  submitted  and  reviewed.  The  capture  of  this  information  as  it  is 
created  by  manufacturers  and  subcontractors  will  greatly  simplify  the 
creation  of  final  project  handover  documents. 

Construction  contractors  identify  the  schedule  for  the  delivery  of  submit¬ 
tals.  “Transmittals”  provide  the  official  delivery  of  the  actual  “Documents” 
that  are  ultimately  “Approved”  by  the  construction  manager.  Of  critical 
concern  to  data  later  in  the  COBIE  Pilot  Implementation  spreadsheet  is 
the  “Document”  worksheet.  The  identifiers  in  the  document  worksheet  al¬ 
low  those  documents  to  be  referenced  where  appropriate  throughout  the 
remainder  of  the  COBIE  spreadsheet. 

A  disk  that  provides  the  COBIE  Pilot  Implementation  spreadsheet  shall 
also  contain  the  list  of  all  individual  files  identified  in  the  “Document” 
worksheet.  A  copy  of  all  files  identified  in  the  “Document”  worksheet  must 
accompany  each  submission  of  the  COBIE  spreadsheet. 


Table  5-3.  Submittal  worksheets. 


Worksheet 

Purpose 

Author 

10 

Schedule 

The  planned  and  needed-by  dates  for  submittals 

Contractor 

11 

Document 

Documents  referenced  in  this  file 

Contr./Mfg 

12 

Transmittal 

Transmittals  for  given  submittal  register  item 

Contractor 

13 

Action 

The  approval  status  of  transmittals/submittals 

Owner  Rep. 

As  construction  proceeds,  materials,  components,  and  equipment  are  in¬ 
stalled  (Table  5-4)  on  the  project.  To  capture  information  about  each  spe¬ 
cific  piece  of  installed  equipment  and  those  materials  or  components  that 
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may  be  specifically  called  out  in  construction  documents,  a  set  of  installa¬ 
tion  worksheets  is  provided.  The  “Installation”  worksheet  is  where  in¬ 
stalled  equipment  serial  and  tag  numbers  are  listed. 


Table  5-4.  Installation  worksheets. 


Worksheet 

Purpose 

Author 

14 

Installation 

Location  and  serial  no.  of  installed  components 

Contr./Mfg 

15 

Manual 

Instruction  manuals  for  sets  of/or  components 

Contr./Mfg 

16 

Warranty 

Warranty  information  for  sets  of/or  components 

Contr./Mfg 

17 

Spare 

Spare  parts  info  provided  for  sets  of/or  components 

Contr./Mfg 

As  building  systems  are  completed,  the  systems  are  tested  for  compliance 
with  contractual  requirements.  “Commissioning”  worksheets.  Table  5-5, 
identify  the  data  needed  to  verify  correct  installation  of  those  portions  of  a 
design  that  require  “Test”  or  “Certification”  results  prior  to  acceptance  by 
the  owner.  “Instructions”  are  system-oriented  documents  that  may  contain 
any  number  of  different  types  of  procedures  for  system  operations. 


Table  5-5.  Commissioning  worksheets. 


Worksheet 

Purpose 

Author 

18 

Instruction 

Installation/operating  instructions 

Contr./Mfg 

19 

Test 

System/component  test  results 

Contractor 

20 

Certification 

Installation  certifications 

Contr./Mfg 

The  final  two  sets  of  information  work  together  to  identify  the  resources 
and  tasks  needed  to  complete  manufacturer  recommended  procedures. 
Since  resources  may  be  applied  on  multiple  tasks,  the  set  of  “Resource” 
worksheets.  Table  5-6,  appears  in  the  COBIE  standard  prior  to  the  job  plan 
worksheet  set.  The  three  types  of  resources  identified  by  expert  facility 
maintenance  personnel  for  inclusion  in  COBIE  are  “Materials”,  “Tools”, 
and  “Training.” 


Table  5-6.  Resource  worksheets. 


Worksheet 

Purpose 

Author 

21 

Material 

Special  materials  needed  for  a  given  Job  Plan  Task 

Contr./Mfg 

22 

Tool 

Special  tools  needed  for  a  given  Job  Plan  Task 

Contr./Mfg 

23 

Training 

Special  training  needed  for  a  given  Job  Plan  Task 

Contr./Mfg 

The  final  set  of  COBIE  worksheets.  Table  5-7,  the  procedures  needed  to 
maintain  and  operate  the  facility.  The  types  of  job  plans  identified  below. 
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as  well  as  the  resource  types  required,  were  identified  during  meetings 
with  COBIE  stakeholders. 


Table  5-7.  Job  plan  worksheets. 


Worksheet 

Purpose 

Author 

24 

PM 

Identifies  specific  PM  tasks  and  frequency 

Contr./Mfg 

25 

Safety 

Identifies  required  safety  tasks 

Contr./Mfg 

26 

Trouble 

Maintenance  troubie  shooting  procedures 

Contr./Mfg 

27 

Start-Up 

Start-up  procedures 

Contr./Mfg 

28 

Shut-Down 

Shut-down  procedures 

Contr./Mfg 

29 

Emergency 

Emergency  operating  procedures 

Contr./Mfg 

COBIE  data  types 

To  clearly  identify  the  requirements  of  the  COBIE  Pilot  Implementation 
Standard,  information  about  the  data  types  identified  in  the  worksheets 
(Section  o)  is  provided.  To  the  extent  possible  there  is  a  direct  mapping 
between  the  data  types  identified  in  this  section  and  data  types  supported 
by  the  lEC  model. 

Reference  data  types 

Reference  data  types  are  those  that  identify  or  reference  individual  records 
within  COBIE  worksheets. 

Integer  (LUID) 

The  LUID  is  a  non-zero  positive  integer  that  for  a  given  worksheet  is  re¬ 
quired  to  be  ascending  by  row  number  and  non-repeating.  In  the  COBIE 
Pilot  Implementation  Standard  once  a  record  has  been  saved  the  data  as¬ 
sociated  with  the  LUID  may  not  be  changed  by  later  users  (Section  o, 
“Change  history”). 

Integer  (loeal  key) 

The  local  key  is  a  non-zero  positive  integer  that  for  a  given  worksheet  must 
be  found  in  the  list  of  worksheet  LUIDs.  The  local  key  allows  worksheet 
data  to  reference  itself  to  identify  “made-of  ’  relationships  among  similar 
COBIE  worksheet  data. 

Integer  (foreign  key) 

The  foreign  key  is  a  non-zero  positive  integer  that  for  a  given  use  must  be 
found  in  the  list  of  LUIDs  of  the  referenced  worksheet.  The  Eoreign  key 


ERDC/CERLTR-07-30 


121 


allows  worksheet  data  on  a  given  worksheet  to  refer  to  data  on  a  different, 
or  “foreign,”  worksheet.  The  foreign  key  allows  worksheet  data  to  identify 
“part-of,”  “created-by,”  and  other  relationships  among  COBIE  worksheet 
data. 

Calculated  references  (foreign  key) 

While  direct  use  of  the  COBIE  spreadsheet  for  data  entry  may  not  be  the 
optimal  solution,  until  such  time  as  software  is  provided  to  fully  support 
the  exchange  of  COBIE  data  many  users,  particularly  at  the  construction 
site,  may  find  it  easier  to  directly  use  a  blank  sample  spreadsheet  rather 
than  use  full  BIM  software.  In  this  case,  selecting  the  integer  ID  number  of 
the  foreign  key  may  prove  difficult.  In  some  cases  errors  can  be  expected 
as  users  refer  back  and  forth  between  sheets.  To  assist  in  reductions  of  di¬ 
rect  data  entry  errors  and  new  field  type,  calculated  references  are  pro¬ 
vided. 

Calculated  reference  fields  combine  the  ID  number,  i.e.,  the  foreign  key, 
required  by  the  Integer  (foreign  key)  data  type  and  the  name  of  the  data 
from  the  row  referred  to  by  the  foreign  key.  Eor  example,  when  selecting 
the  floor  on  which  a  space  is  located,  the  calculated  reference  (foreign  key) 
value  will  provide  both  the  ID  number  of  the  floor  and  the  name  of  the 
floor.  A  comma  will  separate  the  foreign  key  from  the  description.  Users 
directly  using  the  spreadsheet  will,  therefore,  be  able  to  select  the  correct 
floor  without  referring  to  the  Eloor  worksheet. 

The  integer  foreign  key  field  requires  that  the  field  contain  a  single,  posi¬ 
tive  integer.  The  selection  of  the  integer  foreign  key  selected  by  a  calcu¬ 
lated  reference  foreign  key  is  accomplished  by  the  selection  of  the  number 
to  the  left  of  the  comma.  Eor  example  the  calculated  reference  selection 
may  result  in  a  value  of  “loi.  Circuit,  isAmp”.  A  simple  algorithm  to  test 
for  the  existence  of  a  comma  and  only  capture  the  information  to  the  left  of 
the  comma,  i.e.,  “lOi,”  May  be  easily  implemented  to  support  this  needed 
usability  feature  within  the  spreadsheet. 

Calculated  references  are  not  allowed  in  the  Integer  List  data  type.  This 
will  ensure  that  the  situation  posed  by  the  string  "loi.  Circuit,  isAmp, 

203,  Damper,  Eire"  is  not  allowed.  The  correct  presentation  of  the  selected 
value  is  “101,203”.  Note  that  in  most  cases  Integer  List  data  types  are  op¬ 
tional  fields  and  would  most  likely  only  be  generated  directly  from  BIM  or 
other  software  solutions. 
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Integer  list  (foreign  keys) 

The  list  of  foreign  keys  is  a  comma-delimited  list  of  non-zero  positive  inte¬ 
gers  that  for  a  given  use  must  be  found  in  the  list  of  LUIDs  of  the  refer¬ 
enced  worksheet.  The  List  of  Foreign  Keys  allows  all  appropriate  records 
in  the  referenced  worksheet  to  be  linked  to  the  current  worksheet  record. 
Calculated  references  are  not  allowed  in  the  Integer  List  data  type. 

External  referenees 

All  reference  data  types  in  COBIE  worksheets  are  local  references.  If  users 
of  COBIE  data  need  to  pass  external  references  to  data  within  COBIE,  then 
they  may  do  so  using  the  external  reference  fields  provided  on  specific 
worksheets.  It  is  possible  that  different  authors  may  want  to  reference  dif¬ 
ferent  internal  systems.  In  all  cases  the  referenced  system  name  and  the  id 
from  the  reference  system  may  be  provided  by  the  user  creating  the  COBIE 
record. 

An  example  where  an  external  reference  may  be  applied  is  in  the  case  of 
multiple  facilities  being  constructed  under  the  same  contract.  In  this  case, 
the  owner  may  have  an  existing  unique  property  ID  number  for  each  facil¬ 
ity.  To  assist  in  importing  of  the  facility  data,  COBIE  specifications  may 
require  the  submitter  of  the  COBIE  data  to  include  this  unique  identifier 
with  the  related  facility  record. 

Standard  data  types 

Standard  data  types  are  those  that  contain  data  defining  the  contents  of 
the  record  identified  by  the  LUID. 

Text  (50) 

An  alphanumeric  field  containing  no  more  than  50  characters. 

Text  (255) 

An  alphanumeric  field  containing  no  more  than  255  characters. 

Positive  deeimal  number 

A  numeric  field  containing  positive  numbers  that  may  contain  decimal 
portions.  In  many  software  systems  such  numbers  would  be  represented 
by  the  non-zero  positive  real  numbers. 

A  maximum  of  two  decimal  places  will  be  provided  for  positive  decimal 
number. 
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Date  (dd-MMM-yyyy) 

Date  fields  are  provided  in  the  format  that  has  as  example,  “3i-Dec-2006”. 
This  format  provides  a  complete  unambiguous  interpretation  that  may  be 
imported  into  any  locally  required  data  format.  All  dates  will  be  created 
based  on  the  local  clock  of  the  user  who  created  the  data. 

Time  (loeal  24  hour  eloek) 

Time  fields  are  provided  in  the  format  that  has  as  an  example,  “23:59” 

This  example  value  translates  into  11:59  PM-  Use  of  twenty-four  hour  clock 
provides  an  unambiguous  value  for  time.  Seconds  are  not  required  to  be 
transferred  within  COBIE.  All  times  will  be  created  based  on  the  local 
clock  of  the  user  who  created  the  data. 

Classification  data  types 

Classification  data  types  are  those  whose  values  are  bound  by  the  values 
identified  in  the  associated  classification  list.  Classification  data  types  in 
COBIE  are  listed  below  in  alphabetical  order. 

Classifieation  (AetionType) 

The  AetionType  classification  (Table  5-8)  identifies  the  action  taken  when 
Quality  Assurance  personnel  determine  the  status  contractor  quality  con¬ 
trol  submittal. 


Table  5-8.  AetionType  classification. 
Approved 

Approved,  with  comment 
Approved,  resubmittal  required 
Denied,  resubmittal  required 
Receipt  Acknowledged 
Information  Only 


Classifieation  (ApprovalType) 

The  ApprovalType  classification  (Table  5-9)  identifies  the  level  of  approval 
required  when  submitting  construction  contactor  submittals  as  part  of  a 
contractor  quality  control  process. 
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Table  5-9.  ApprovalType  classification. 
Owner  Approval 
Contractor  Certified 
Information  Oniy 


Classification  (Areallnit) 

The  AreaUnit  classification  (Table  5-10)  identifies  the  units  of  area  meas¬ 
urements  to  be  allowed  within  the  COBIE  specification. 

Table  5-10.  AreaUnit  classification. 

Squareinches 

Squa  refeet 

Squaremiies 

Squaremiiiimeters 

Squaremeters 

Squarekiiometers 


Classification  (AssetType) 

The  AssetType  classification  (Table  5-11)  allows  materials,  products,  and 
equipment  identified  by  a  project  designer  to  be  classified  for  asset  man¬ 
agers  into  assets  that  are  fixed  parts  of  the  project  and  those  that  may  be 
moved  following  project  handover. 

Table  5-11.  AssetType  classification. 

Fixed 

Moveabie 


Classification  (AttributeSetType) 

The  AttributeSetType  classification  allows  an  attribute  set  to  be  identified 
by  category  (Table  5-12).  This  set  is  consistent  with  property  set  types  in 
the  IFC  model. 
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Table  5-12.  AttributeSetType  classification. 


SingleValue 


EnumeratedValue 


BoundedValue 


TableValue 


ReferenceValue 


ListValue 


SetValue 


Classification  (CoordinateType) 

The  CoordinateType  classification  (Table  5-13)  allows  objects  within 
COBIE  to  be  physically  located  within  a  locally  defined,  three  dimensional 
geometry  according  to  one  of  three  constructs:  single  point,  two  ends  of  a 
line,  or  bounding  corners  of  a  box.  Box  coordinates  of  “lowerleft”  and  “up- 
perright”  are  determined  in  accordance  with  the  local  origin  for  informa¬ 
tion  contained  in  the  COBIE  worksheet. 


Table  5-13.  CoordinateType  classification. 


Classification  (CostUnit) 

The  CostUnit  classification  (Table  5-14)  allows  COBIE  cost  values  to  be 
identified  with  their  appropriate  currency.  Additional  currencies  may  be 
added  for  projects  funded  with  local  government,  or  a  mix  of  different, 
currencies.  These  additional  currency  values  must  be  identified  in  the  con¬ 
tract  language  requiring  COBIE  data  exchange. 

Table  5-14.  CostUnit  classification. 

Dollars 

Euros 


Classification  (DurationUnit) 

The  DurationUnit  classification  (Table  5-15)  allows  COBIE  planning  data 
to  be  used  to  construct  project  and  maintenance  schedules. 
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Table  5-15.  DurationUnit  classification. 


Classification  (JobStatusType) 

The  Job  Status  Type  classification  (Table  5-16)  allows  the  construction 
contractor  to  inform  the  facility  operator  if  specific  required  maintenance 
items  were  completed  prior  to  the  handover  of  the  building  at  beneficial 
occupancy. 


Table  5-16.  JobStatusType  classification. 

Not  Yet  Started 

Started 

Completed 


Classification  (LinearUnit) 

The  LinearUnit  classification  (Table  5-17)  identifies  the  units  of  linear 
measurements  to  be  allowed  within  the  COBIE  specification. 


Table  5-17.  LinearUnit  classification. 


Classification  (RegisterType) 

The  RegisterType  classification  (Table  5-18)  allows  the  designer  to  identify 
the  type  of  contractor  quality  control  submittal  required. 
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Table  5-18.  RegisterType  classification. 

Preconstruction  Submittals 

Shop  Drawings 

Product  Data 

Samples 

Design  Data 

Test  Reports 

Certificates 

Manufacturer  Instructions 
Manufacturer  Field  Reports 
Operation  and  Maintenance 
Closeout  Submittals 


Classification  (SpareType) 

The  SpareType  classification  (Table  5-19)  allows  the  construction  contrac¬ 
tor  to  identify  the  type  of  part  that  is  required  to  maintain  a  given  piece  or 
set  of  equipment. 


Table  5-19.  SpareType  classification. 


Classification  (OmniClassi3,  Space  Function) 

The  OmniClass  Table  13,  Space  Function,  classification  allows  the  designer 
to  identify  the  primary  purpose  of  a  given  space. 

Aggregation  of  space  measurement  and  asset  information  against  the 
Space  Function  classification  scheme  provides  information  required  by 
asset  managers  at  construction  handover. 

Classification  (OmniClasssi,  System  Function) 

The  OmniClass  Table  21,  System  Function,  classification  allows  the  de¬ 
signer  to  identify  the  primary  purpose  of  a  given  system  of  parts  within  a 
given  building.  This  classification  allows  the  facility  manager  to  map  the 
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data  within  COBIE  to  their  own  internal  classification  of  resources  used 
for  facility  operations  and  maintenance. 

Aggregation  of  installed  equipment  associated  with  individual  system 
function  classifications  provides  information  required  by  asset  managers 
at  construction  handover. 

Classification  (OmniClassss,  Product) 

The  OmniClass  Table  23,  Product,  classification  allows  the  designer  to 
identify  the  primary  purpose  of  a  given  product  within  a  given  building. 
This  classification  allows  the  facility  manager  to  map  the  data  within 
COBIE  to  their  own  internal  classification  of  products  used  for  facility  op¬ 
erations  and  maintenance. 

Classification  (OmniClass34,  Actor) 

The  OmniClass  Table  34,  Actor,  classification  allows  the  construction 
manager  to  identify  the  role  that  all  the  persons  identified  throughout  the 
COBIE  database  played  in  the  given  project.  It  may  also  be  possible  to  use 
this  information  in  future  software  implementation  to  limit  write  access  to 
certain  COBIE  data  based  on  the  user’s  role. 

COBIE  worksheet  definitions 

There  are  29  individual  worksheets  in  every  COBIE  file.  Table  5-20  - 
Table  5-48  list  the  data  fields  required  for  each  worksheet. 

Each  table  definition  begins  with  header  information  describing  the  name 
of  the  worksheet  and  the  required  content.  Header  information  identifies 
if  data  is  required,  or  optional.  If  optional,  requirements  under  which  the 
data  may  be  required  are  identified. 

In  the  case  where  COBIE  data  is  required  to  be  submitted  at  construction 
handover,  the  author  of  all  COBIE  data  will  be  the  person  collating  COBIE 
data  for  the  prime  contractor.  However,  in  cases  where  COBIE  data  is  to 
be  submitted  during  the  design  and  construction  process  the  author  of  the 
COBIE  data  may  not  be  the  prime  construction  contractor.  Header  infor¬ 
mation  identifies  the  expected  authors  of  the  COBIE  information,  if  col¬ 
lected  during  the  process  of  design  and  construction. 

The  header  section  for  each  worksheet  concludes  with  a  listing  of  any  op¬ 
tions  that  are  relevant  to  assist  in  the  description  of  the  worksheet. 
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Following  the  general  information  provided  in  the  header,  a  listing  of  each 
of  the  columns  to  be  created  in  a  COBIE  spreadsheet  is  provided.  Re¬ 
quirements  for  column,  column  name,  format,  and  the  data  are  provided. 
The  definitions  for  all  formats  for  each  COBIE  data  column  were  described 
above  in  Section  o.  Notes  to  software  vendors  implementing  the  COBIE 
spreadsheet  are  found  in  Section  o. 


Table  5-20.  Worksheet  01:  Contact  (Required). 


WORKSHEET  NAME 

Contact 

CONTENT 

People/offices/companies  referenced  in  this  file. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Anyone  that  provides  or  creates  COBIE  data 

ALTERNATE  AUTHOR 

n/a 

OPTIONS 

n/a 

Column 

Column  Name 

Data  Type 

Reqd 

A 

ContactID 

Integer  (LUID) 

Yes 

B 

ContactRole 

Classification  (0mniClass34) 

Yes 

C 

ExternalSystemName 

Text  (50) 

If  Needed 

D 

ExternalNamelD 

Text  (50) 

If  Needed 

E 

External  Office  ID 

Text  (50) 

If  Needed 

F 

GivenName 

Text  (50) 

Yes 

G 

FamilyName 

Text  (50) 

Yes 

H 

OfficeName 

Text  (255) 

Yes 

1 

OfficeDepartment 

Text  (50) 

Opt 

J 

OfficeOrganizationCode 

Text  (50) 

Opt 

K 

AddressStreet 

Text  (255) 

Yes 

L 

AddressPostalBox 

Text  (50) 

Opt 

M 

AddressTown 

Text  (50) 

Yes 

N 

Ad  d  ressState  Regi  o  n 

Text  (50) 

Yes 

0 

AddressPostalCode 

Text  (50) 

Yes 

P 

AddressCountry 

Text  (50) 

Opt 

Q 

ContactPhone 

Text  (50) 

Yes 

R 

ContactFax 

Text  (50) 

Opt 

S 

ContactEmail 

Text  (255) 

Yes 

T 

Created  By 

Integer  (Local  Key) 

Yes 

U 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

V 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

w 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

X 

Withdrawn 

Yes/ No 

Yes 

Y 

ContactIDPick 

Calculated  Ref.  A,E,F,H 

Automatic 
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Table  5-21.  Worksheet  02:  Facility  (Required). 


WORKSHEET  NAME 

Facility 

CONTENT 

Identification  of  facility(ies)  referenced  in  a  file 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-built  data) 

OPTIONS 

Links  to  existing  asset  management  systems  occurs  through 
data  provided  Columns  B  &  C.  All  references  to  facilities  infor¬ 
mation  in  COBIE  information  exchanges  are  local. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

FacilitylD 

Integer  (LUID) 

Yes 

B 

ExternalSystemName 

Text  (50) 

If  Needed 

C 

ExternalNamelD 

Text  (50) 

If  Needed 

D 

FacilityName 

Text  (50) 

Yes 

E 

FacilityDescription 

Text  (255) 

Opt 

F 

Created  By 

Integer  (Foreign  Key) 

Yes 

G 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

H 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

1 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

J 

Withdrawn 

Yes/ No 

Yes 

K 

FacilityIDPick 

Calculated  Ref.  A,D 

Automatic 
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Table  5-22.  Worksheet  03:  Floor  (Required). 


WORKSHEET  NAME 

Floor 

CONTENT 

Description  of  vertical  levels 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-built  data) 

Column 

Column  Name 

Data  Type 

Reqd 

A 

FloorlD 

Integer  (LUID) 

Yes 

B 

FacilitylD 

Integer  (Foreign  Key) 

Yes 

C 

ReferenceFloorlD 

Integer  (Local  Key) 

If  Needed 

D 

ExternalSystemName 

Text  (50) 

If  Needed 

E 

ExternalNamelD 

Text  (50) 

If  Needed 

F 

FloorName 

Text  (50) 

Yes 

G 

FloorDescription 

Text  (255) 

Opt 

H 

FloorElevation 

Positive  Decimal  Number 

Opt 

1 

FloorElevationUnits 

Classification  (Linear  Unit) 

Opt 

J 

FloorTotalHeight 

Positive  Decimal  Number 

Opt 

K 

FloorTotalHeightUnits 

Classification  (Linear  Unit) 

Opt 

L 

ExteriorGrossArea 

Positive  Decimal  Number 

Opt 

M 

ExteriorGrossAreaUnit 

Classification  (AreaUnit) 

Opt 

N 

InteriorGrossArea 

Positive  Decimal  Number 

Opt 

0 

InteriorGrossAreaUnit 

Classification  (AreaUnit) 

Opt 

P 

PlannableGrossArea 

Positive  Decimal  Number 

Opt 

Q 

PlannableGrossAreaUnit 

Classification  (AreaUnit) 

Opt 

R 

RentableAreaUsableArea 

Positive  Decimal  Number 

Opt 

S 

RentableAreaUsableAreaUnits 

Classification  (AreaUnit) 

Opt 

T 

InteriorPlannableArea 

Positive  Decimal  Number 

Opt 

U 

InteriorPlannableAreaUnits 

Classification  (AreaUnit) 

Opt 

V 

CalculationMethod 

Text  (50) 

Opt 

w 

Created  By 

Integer  (Foreign  Key) 

Yes 

X 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

Y 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

z 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

AA 

Withdrawn 

Yes/ No 

Yes 

AB 

FloorlDPick 

Calculated  Ref.  A,D 

Automatic 
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Table  5-23.  Worksheet  04:  Space  (Required). 


WORKSHEET  NAME 

Space 

CONTENT 

Spaces  identified  within  a  given  floor 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-built  data) 

Column 

Column  Title 

Data  Type 

Reqd 

A 

SpacelD 

Integer  (LUID) 

Yes 

B 

FloorlD 

Integer  (Foreign  Key) 

Yes 

C 

SpaceFunction 

Classification(OmniClassl3) 

Yes 

D 

SpaceReferencelD 

Integer  (Local  Key) 

If  Needed 

E 

ExternalSystemName 

Text  (50) 

If  Needed 

F 

ExternalNamelD 

Text  (50) 

If  Needed 

G 

SpaceNumber 

Text  (50) 

Yes 

H 

SpaceName 

Text  (50) 

Opt 

1 

SpaceDescription 

Text  (255) 

Opt 

J 

SpaceUsableHeight 

Positive  Decimal  Number 

Opt 

K 

SpaceUsableHeightUnits 

Classification  (LinearUnit) 

Opt 

L 

ExteriorGrossArea 

Positive  Decimal  Number 

Opt 

M 

ExteriorG  rossArea  U  n  it 

Classification  (AreaUnit) 

Opt 

N 

InteriorGrossArea 

Positive  Decimal  Number 

Opt 

0 

InteriorGrossAreaUnit 

Classification  (AreaUnit) 

Opt 

P 

PlannableGrossArea 

Positive  Decimal  Number 

Opt 

Q 

Plan  na  bleG  rossArea  U  n  it 

Classification  (AreaUnit) 

Opt 

R 

RentableAreaUsableArea 

Positive  Decimal  Number 

Opt 

S 

Renta  bleAreaUsableArea  Units 

Classification  (AreaUnit) 

Opt 

T 

InteriorPlannableArea 

Positive  Decimal  Number 

Opt 

U 

InteriorPlannableAreaUnits 

Classification  (AreaUnit) 

Opt 

V 

CalculationMethod 

Text  (50) 

Opt 

w 

Created  By 

Integer  (Foreign  Key) 

Yes 

X 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

Y 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

z 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

AA 

Withdrawn 

Yes/ No 

Yes 

AB 

SpacelDPick 

Calculated  Ref.  A,E 

Automatic 
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Table  5-24.  Worksheet  05:  System  (Required). 


WORKSHEET  NAME 

System 

CONTENT 

Systems  referenced  in  a  project 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-buiit  data) 

OPTIONS 

Sub  systems  and  zones  may  be  identified  through  System¬ 
ReferencelD 

Column 

Column  Title 

Data  Type 

Reqd 

A 

System  ID 

Integer  (LUID) 

Yes 

B 

FacilitylD 

Integer  (Foreign  Key) 

Yes 

C 

SystemFunction 

Ciassification  (OmniCiass21) 

Yes 

D 

SystemReferencelD 

Integer  (Local  Key) 

If  Needed 

E 

Exte  rn  a  1  Syste  m  Na  m  e 

Text  (50) 

If  Needed 

F 

ExternalNamelD 

Text  (50) 

If  Needed 

G 

SystemName 

Text  (50) 

Yes 

H 

SystemDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 

N 

FacilityIDPick 

Calculated  Ref.  A,E 

Automatic 
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Table  5-25.  Worksheet  06:  Register  (Required). 


WORKSHEET  NAME 

Register 

CONTENT 

Materiai/equipment/etc.  cataiog 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-buiit  data) 

OPTIONS 

This  is  equivaientto  the  submittai  register  created  as  part  of 
the  construction  documents. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

RegisterlD 

Integer  (LUID) 

Yes 

B 

ProductType 

Classification  (OmniClass23) 

Yes 

C 

RegisterType 

Classification  (Register) 

Yes 

D 

AssetType 

Classification  (AssetType) 

Yes 

E 

RegisterApprovalBy 

Classification  (Approval) 

Yes 

F 

SystemIDList 

Integer  List  (Foreign  Key) 

If  Needed 

G 

SpacelDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

ExternalSystemName 

Text  (50) 

If  Needed 

1 

ExternalNamelD 

Text  (50) 

If  Needed 

J 

RegisterName 

Text  (50) 

Yes 

K 

RegisterReference 

Text  (255) 

Opt 

L 

ReplacementCost 

Positive  Decimal  Number 

Opt 

M 

ReplacementCostUnit 

Classification  (CostUnit) 

Opt 

N 

Expected  Life 

Positive  Decimal  Number 

Opt 

0 

Expected  LifeUnit 

Classification  (DurationUnit) 

Opt 

P 

Created  By 

Integer  (Foreign  Key) 

Yes 

Q 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

R 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

S 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

T 

Withdrawn 

Yes/ No 

Yes 

U 

RegisterlDPick 

Calculated  Ref.  A,H 

Automatic 
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Table  5-26.  Worksheet  07:  Component  (Required). 


WORKSHEET  NAME 

Component 

CONTENT 

Individually  named  materials  and  equipment 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-built  data) 

OPTIONS 

All  named  items  including,  but  not  limited  to,  mechanical 
equipment  such  as  “AHU-1,”  must  appear  in  this  worksheet. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

ComponentID 

Integer  (LUID) 

Yes 

B 

SpacelD 

Integer  (Foreign  Key) 

Yes 

C 

RegisterlD 

Integer  (Foreign  Key) 

Yes 

D 

ExternalSystemName 

Text  (50) 

If  Needed 

E 

ExternalNamelD 

Text  (50) 

If  Needed 

F 

ComponentName 

Text  (50) 

Yes 

G 

ComponentDescription 

Text  (255) 

Opt 

H 

Created  By 

Integer  (Foreign  Key) 

Yes 

1 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

J 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

K 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

L 

Withdrawn 

Yes/ No 

Yes 

M 

IDPick 

Calculated  Ref.  A,D 

Automatic 
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Table  5-27.  Worksheet  08:  Attribute  (Optional). 


WORKSHEET  NAME 

Attribute 

CONTENT 

Materiai/equipment/etc.  properties 

REQUIRED 

Optionai 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-buiit  data) 

OPTIONS 

If  specific  attributes  are  defined  by  the  enabiing  contract 
documents,  these  attributes  shaii  be  provided  in  this  work¬ 
sheet. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

AttributelD 

Integer  (LUID) 

Yes 

B 

AttributeSetType 

Classification  (PropertyType) 

Yes 

C 

AttributeReferencelD 

Integer  (Local  Key) 

If  Needed 

D 

System  ID 

Integer  (Foreign  Key) 

If  Needed 

E 

RegisterlD 

Integer  (Foreign  Key) 

If  Needed 

F 

TransmittallD 

Integer  (Foreign  Key) 

If  Needed 

G 

InstallationID 

Integer  (Foreign  Key) 

If  Needed 

H 

SpacelDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

AttributeName 

Text  (50) 

Yes 

J 

AttributeDescription 

Text  (255) 

Opt 

K 

AttributeValue 

Text  (50) 

Yes 

L 

AttributeUnit 

Text  (50) 

Yes 

M 

AttributeReference 

Text  (50) 

Opt 

N 

AttributePriority 

Text  (50) 

Opt 

0 

Created  By 

Integer  (Foreign  Key) 

Yes 

P 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

Q 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

R 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

S 

Withdrawn 

Yes/No 

Yes 

T 

IDPick 

Calculated  Ref.  A,l 

Automatic 
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Table  5-28.  Worksheet  09:  Coordinate  (Optional). 


WORKSHEET  NAME 

Coordinate 

CONTENT 

Location  of  spaces  and  components 

REQUIRED 

Optionai 

PRIMARY  AUTHOR 

Designer 

ALTERNATE  AUTHOR 

Construction  Contractor  (updates  with  as-buiit  data) 

OPTIONS 

If  coordinates  for  specific  parts  of  the  faciiity  are  required  by 
the  enabiing  contract  documents,  those  coordinates  shaii  be 
provided  in  this  worksheet. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

CoordinatelD 

Integer  (LUID) 

Yes 

B 

CoordinateType 

Classification  (Coord.  Type) 

Yes 

C 

FacilitylD 

Integer  (Foreign  Key) 

If  Needed 

D 

FloorlD 

Integer  (Foreign  Key) 

If  Needed 

E 

SpacelD 

Integer  (Foreign  Key) 

If  Needed 

F 

ComponentID 

Integer  (Foreign  Key) 

If  Needed 

G 

InstallationID 

Integer  (Foreign  Key) 

If  Needed 

H 

CoordinateXAxis 

Positive  Decimal  Number 

Yes 

1 

CoordinateXAxisUnit 

Classification  (LinearUnit) 

Yes 

J 

CoordinateYAxis 

Positive  Decimal  Number 

Yes 

K 

CoordinateYAxisUnit 

Classification  (LinearUnit) 

Yes 

L 

CoordinateZAxis 

Positive  Decimal  Number 

Yes 

M 

CoordinateZAxisUnit 

Classification  (LinearUnit) 

Yes 

N 

Created  By 

Integer  (Foreign  Key) 

Yes 

0 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

P 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

Q 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

R 

Withdrawn 

Yes/ No 

Yes 
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Table  5-29.  Worksheet  10:  Schedule  (Optional). 


WORKSHEET  NAME 

Schedule 

CONTENT 

The  planned  and  needed-by  dates  for  construction  submittals 

REQUIRED 

Not  required,  unless  specified 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor{s) 

OPTIONS 

References  to  CPM  schedules  occurs  through  ExternalSched¬ 
uleActivity  field. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

SchedulelD 

Integer  (LUID) 

Yes 

B 

RegisterlD 

Integer  (Foreign  Key) 

Yes 

C 

SubmitBy 

Date  (dd-MMM-yyyy) 

Yes 

D 

ApproveBy 

Date  (dd-MMM-yyyy) 

Yes 

E 

DeliverBy 

Date  (dd-MMM-yyyy) 

Yes 

F 

ExternalScheduleActivity 

Text  (50) 

Opt 

G 

Created  By 

Integer  (Foreign  Key) 

Yes 

H 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

1 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

J 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

K 

Withdrawn 

Yes/ No 

Yes 
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Table  5-30.  Worksheet  11:  Document  (Required). 


WORKSHEET  NAME 

Document 

CONTENT 

References  to  every  document  provided  through  the  COBIE  data 
format. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Manufacturers,  Subcontractor(s) 

OPTIONS 

Aii  documents  referenced  shaii  be  submitted  with  the  COBIE 
data.  Default  format  for  documents,  unless  otherwise  notified, 
should  be  Portable  Document  Format  (PDF).  Documents  identi¬ 
fied  here  are  referenced  through  the  remainder  of  the  COBIE 
format,  where  appropriate. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

DocumentID 

Integer  (LUID) 

Yes 

B 

ExternalSystemName 

Text  (50) 

If  Needed 

C 

Externa  ISystem  ID 

Text  (50) 

If  Needed 

D 

DocumentName 

Text  (255) 

Yes 

E 

DocumentDirectoryName 

Text  (255) 

Yes 

F 

DocumentFileName 

Text  (255) 

Yes 

G 

DocumentType 

Text  (50) 

Yes 

H 

Created  By 

Integer  (Foreign  Key) 

Yes 

1 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

J 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

K 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

L 

Withdrawn 

Yes/ No 

Yes 

M 

IDPick 

Calculated  Ref.  A,E 

Automatic 
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Table  5-31.  Worksheet  12:  Transmittal  (Optional). 


WORKSHEET  NAME 

Transmittal 

CONTENT 

Record  of  transmitting  documents  from  Construction  Contractor 
to  Quality  Assurance  staff. 

REQUIRED 

Not  required,  unless  specified 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

n/a 

Column 

Column  Title 

Data  Type 

Reqd 

A 

TransmittallD 

Integer  (LUID) 

Yes 

B 

RegisterlD 

Integer  (Foreign  Key) 

Yes 

C 

DocumentID 

Integer  (Foreign  Key) 

Yes 

D 

TransmittalNumber 

Text  (50) 

Yes 

E 

TransmittalRevision 

Text  (50) 

Yes 

F 

TransmittalDeviation 

Text  (50) 

Yes 

G 

TransmittalName 

Text  (255) 

Yes 

H 

TransmittalDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 

N 

IDPick 

Calculated  Ref.  A,G 

Automatic 

Table  5-32.  Worksheet  13:  Action  (Optional). 


WORKSHEET  NAME 

Action 

CONTENT 

Record  of  action  by  the  Quality  Assurance  staff  on  individual 
transmittals  and/or  entire  submittal  packages 

REQUIRED 

Not  required,  unless  specified 

PRIMARY  AUTHOR 

Quality  Assurance  Staff 

ALTERNATE  AUTHOR 

n/a 

Column 

Column  Title 

Data  Type 

Reqd 

A 

ActionID 

Integer  (LUID) 

Yes 

B 

RegisterlD 

Integer  (Foreign  Key) 

Yes 

C 

ActionCode 

Classification  (Action  Type) 

Yes 

D 

TransmittallD 

Integer  (Foreign  Key) 

Opt 

E 

ActionDescription 

Text  (255) 

Opt 

F 

Created  By 

Integer  (Foreign  Key) 

Yes 

G 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

H 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

1 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

J 

Withdrawn 

Yes/ No 

Yes 
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Table  5-33.  Worksheet  14:  Installation  (Required). 


WORKSHEET  NAME 

Installation 

CONTENT 

The  as-built  tag  and  serial  numbers  for  all  installed  equipment. 
The  space  IDs  where  the  equipment  is  installed. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor 

OPTIONS 

If  identified  by  contact,  this  worksheet  shall  also  contain  infor¬ 
mation  about  the  installation  finishes  that  apply  to  multiple 
rooms. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

InstallationID 

Integer  (LUID) 

Yes 

B 

RegisterlD 

Integer  (Foreign  Key) 

Yes 

0 

ComponentID 

Integer  (Foreign  Key) 

If  Needed 

D 

TransmittallD 

Integer  (Foreign  Key) 

If  Needed 

E 

SpacelDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

InstallationName 

Text  (255) 

Yes 

H 

InstallationManufacturer 

Text  (255) 

Yes 

1 

InstallationModel 

Text  (50) 

Yes 

J 

InstallationSerialNumber 

Text  (50) 

Yes 

K 

InstallationTagNumber 

Text  (50) 

Opt 

L 

InstallationDescription 

Text  (255) 

Opt 

M 

CreatedBy 

Integer  (Foreign  Key) 

Yes 

N 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

0 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

P 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Q 

Withdrawn 

Yes/ No 

Yes 

R 

InstallationIDPick 

Calculated  Ref.  A,H,I 

Automatic 
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Table  5-34.  Worksheet  15:  Manual  (Required). 


WORKSHEET  NAME 

Manual 

CONTENT 

Link  between  installation  and  operations  manuals  (contained  in 
Document  worksheet)  for  related  equipment. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Manufacturer 

OPTIONS 

Installation  and  operations  manuals  shall  be  linked  at  the  high¬ 
est  relevant  level.  For  example,  if  there  are  three  pumps  of  the 
same  type,  then  the  link  here  will  be  between  the  DocumentID 
and  the  RegisterlD. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

ManuallD 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

ManualName 

Text  (255) 

Yes 

H 

ManualDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-35.  Worksheet  16:  Warranty  (Required). 


WORKSHEET  NAME 

Warranty 

CONTENT 

Link  between  warranty  certificates  (contained  in  Document 
worksheet)  for  reiated  equipment.  Warranty  data  aiso  provided. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Manufacturer 

OPTIONS 

Warranty  guarantor  iistshaii  reference  companies  identified  in 
the  Contact  worksheet. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

Warranty  ID 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Key) 

Yes 

0 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

D 

GuarantorlDList 

Integer  List  (Foreign  Keys) 

Yes 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

WarrantyName 

Text  (255) 

Yes 

1 

Wa  rra  ntyDescription 

Text  (255) 

Opt 

J 

WarrantyStart 

Date  (dd-MMM-yyyy) 

Yes 

K 

WarrantyEnd 

Date  (dd-MMM-yyyy) 

Yes 

L 

CreatedBy 

Integer  (Foreign  Key) 

Yes 

M 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

N 

CreatedTime 

Time  (iocai  24-hr  ciock) 

Yes 

0 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

P 

Withdrawn 

Yes/ No 

Yes 
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Table  5-36.  Worksheet  17:  Spare  (Required). 


WORKSHEET  NAME 

Spare 

CONTENT 

Link  between  spare  parts  sets  (contained  in  Document  work¬ 
sheet)  for  reiated  equipment.  Part  data  aiso  provided.  If  possi¬ 
ble,  specific  part  data  should  be  provided  by  Manufacturers. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Manufacturer 

OPTIONS 

Part  supplier  list  shall  reference  companies  identified  in  the 
Contact  worksheet. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

SparelD 

Integer  (LUID) 

Yes 

B 

SpareType 

Classification  (Parts  Type) 

Yes 

0 

DocumentIDList 

Integer  List  (Foreign  Keys) 

Yes 

D 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

E 

SpareProviderlDList 

Integer  List  (Foreign  Keys) 

Yes 

F 

SpareSetID 

Integer  (Local  Key) 

If  Needed 

G 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

SpareNumber 

Text  (50) 

Yes 

K 

SpareName 

Text  (255) 

Opt 

L 

SpareDescription 

Text  (255) 

Opt 

M 

CreatedBy 

Integer  (Foreign  Key) 

Yes 

N 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

0 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

P 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Q 

Withdrawn 

Yes/ No 

Yes 

R 

IDPick 

Calculated  Ref.  A,J 

Automatic 
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Table  5-37.  Worksheet  18:  Instructions  (Required). 


WORKSHEET  NAME 

Instructions 

CONTENT 

Link  between  Operating  Instructions  (contained  in  Document 
worksheet)  to  reiated  equipment.  If  possible,  instructions 
should  be  provided  by  Manufacturers. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Manufacturer 

OPTIONS 

Instructions  shall  be  linked  between  the  DocumentID  and  the 
RegisterlD.  Additional  links  are  provided  to  overall  systems  or 
specific  installed  equipment  if  appropriate. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

Instruction  ID 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

InstructionName 

Text  (255) 

Yes 

H 

InstructionDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-38.  Worksheet  19:  Test  (Required). 


WORKSHEET  NAME 

Test 

CONTENT 

Link  between  Test  resuits  (contained  in  Document  worksheet) 
to  reiated  equipment. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Testing  agent 

OPTIONS 

Tests  shaii  be  iinked  between  the  DocumentID  and  the  Regis- 
terlD.  Additionai  iinks  are  provided  to  overaii  systems  or  specific 
instaiied  equipment  if  appropriate. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

TestID 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

TestName 

Text  (255) 

Yes 

H 

TestDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (iocai  24-hr  ciock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-39.  Worksheet  20:  Certification  (Required). 


WORKSHEET  NAME 

Certification 

CONTENT 

Link  between  Certifications  (contained  in  Document  worksheet) 
to  reiated  equipment  or  systems. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Certifying  agent 

OPTIONS 

Certifications  shaii  be  iinked  between  the  DocumentID  and  the 
RegisterlD.  Additionai  iinks  are  provided  to  overaii  systems  or 
specific  instaiied  equipment  if  appropriate. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

CertificationID 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

Yes 

C 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

CertificationName 

Text  (255) 

Yes 

H 

CertificationDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (iocai  24-hr  ciock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-40.  Worksheet  21:  Material  (Required). 


WORKSHEET  NAME 

Material 

CONTENT 

Identification  of  a  material  resource  need  during  the  operations 
and  maintenance  phase  of  a  project. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

The  ID  of  this  resource  will  be  used  in  the  Job  plan  worksheets. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

MateriallD 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

C 

RegisterlDList 

Integer  List  (Foreign  Keys) 

If  Needed 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

MaterialName 

Text  (255) 

Yes 

H 

MaterialDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-41.  Worksheet  22:  Tool  (Required). 


WORKSHEET  NAME 

Tool 

CONTENT 

Identification  of  a  tool  resource  need  during  the  operations  and 
maintenance  phase  of  a  project. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

The  ID  of  this  resource  will  be  used  in  the  Job  plan  worksheets. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

Tool  ID 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

0 

RegisterlDList 

Integer  List  (Foreign  Keys) 

If  Needed 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

ToolName 

Text  (255) 

Yes 

H 

ToolDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-42.  Worksheet  23:  Training  (Required). 


WORKSHEET  NAME 

Training 

CONTENT 

Identification  of  a  training  resource  need  during  the  operations 
and  maintenance  phase  of  a  project. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

The  ID  of  this  resource  wiii  be  used  in  the  Job  pian  worksheets. 

Column 

Column  Title 

Data  Type 

Reqd 

A 

TrainingID 

Integer  (LUID) 

Yes 

B 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

0 

RegisterlDList 

Integer  List  (Foreign  Keys) 

If  Needed 

D 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

TrainingName 

Text  (255) 

Yes 

H 

TrainingDescription 

Text  (255) 

Opt 

1 

Created  By 

Integer  (Foreign  Key) 

Yes 

J 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

K 

CreatedTime 

Time  (iocal  24-hr  ciock) 

Yes 

L 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

M 

Withdrawn 

Yes/ No 

Yes 
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Table  5-43.  Worksheet  24:  PM  (Required). 


WORKSHEET  NAME 

PM 

CONTENT 

Identification  of  sets  of  sequenced  tasks  needed  to  accompiish 
preventative  maintenance  functions.  If  possible  the  specific 
tasks  shall  be  identified  in  this  worksheet.  Linking  to  a  file  con¬ 
taining  tasks,  unless  created  by  manufacturers,  should  be  dis¬ 
couraged. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

Material,  Tool,  and  Training  resources  are  identified  by  refer¬ 
ence. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

PMTaskID 

Integer  (LUID) 

Yes 

B 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

TaskStatus 

Classification  (Task  Status) 

Yes 

D 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

MateriallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

ToollDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

TrainingIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

K 

PriorTaskList 

Integer  List  (Foreign  Keys) 

If  Needed 

L 

Task  Number 

Text  (50) 

Yes 

M 

TaskName 

Text  (50) 

Yes 

N 

TaskDescription 

Text  (255) 

Opt 

0 

TaskDurationValue 

Positive  Decimal  Number 

Yes 

P 

TaskDurationUnit 

Classification  (Duration  Unit) 

Yes 

Q 

TaskStartValue 

Positive  Decimal  Number 

Yes 

R 

TaskStartUnit 

Classification  (Duration  Unit) 

Yes 

S 

TaskFrequencyValue 

Positive  Decimal  Number 

Yes 

T 

TaskFrequencyUnit 

Classification  (Duration  Unit) 

Yes 

U 

Created  By 

Integer  (Foreign  Key) 

Yes 

V 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

w 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

X 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Y 

Withdrawn 

Yes/ No 

Yes 
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Table  5-44.  Worksheet  25:  Safety. 


WORKSHEET  NAME 

Safety 

CONTENT 

Identification  of  sets  of  sequenced  tasks  needed  to  safeiy  op¬ 
erate  referenced  equipment  or  systems.  If  possible  the  specific 
tasks  shall  be  identified  in  this  worksheet.  Linking  to  a  file  con¬ 
taining  tasks,  unless  created  by  manufacturers,  should  be  dis¬ 
couraged. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

Material,  Tool,  and  Training  resources  are  identified  by  refer¬ 
ence. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

SafetyTaskID 

Integer  (LUID) 

Yes 

B 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

TaskStatus 

Classification  (Task  Status) 

Yes 

D 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

MateriallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

ToollDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

TrainingIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

K 

PriorTaskList 

Integer  List  (Foreign  Keys) 

If  Needed 

L 

Task  Number 

Text  (50) 

Yes 

M 

TaskName 

Text  (50) 

Yes 

N 

TaskDescription 

Text  (255) 

Opt 

0 

TaskDurationValue 

Positive  Decimal  Number 

Yes 

P 

TaskDurationUnit 

Classification  (Duration  Unit) 

Yes 

Q 

TaskStartValue 

Positive  Decimal  Number 

Yes 

R 

TaskStartUnit 

Classification  (Duration  Unit) 

Yes 

S 

TaskFrequencyValue 

Positive  Decimal  Number 

Yes 

T 

TaskFrequencyUnit 

Classification  (Duration  Unit) 

Yes 

U 

Created  By 

Integer  (Foreign  Key) 

Yes 

V 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

w 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

X 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Y 

Withdrawn 

Yes/ No 

Yes 
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Table  5-45.  Worksheet  26:  Trouble  (Required). 


WORKSHEET  NAME 

Trouble 

CONTENT 

Identification  of  sets  of  sequenced  tasks  needed  to  trouble¬ 
shoot  referenced  equipment  or  systems.  If  possible  the  specific 
tasks  shall  be  identified  in  this  worksheet.  Linking  to  a  file  con¬ 
taining  tasks,  unless  created  by  manufacturers,  should  be  dis¬ 
couraged. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

Material,  Tool,  and  Training  resources  are  identified  by  refer¬ 
ence. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

TroubleTaskID 

Integer  (LUID) 

Yes 

B 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

TaskStatus 

Classification  (Task  Status) 

Yes 

D 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

MateriallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

ToollDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

TrainingIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

K 

PriorTaskList 

Integer  List  (Foreign  Keys) 

If  Needed 

L 

Task  Number 

Text  (50) 

Yes 

M 

TaskName 

Text  (50) 

Yes 

N 

TaskDescription 

Text  (255) 

Opt 

0 

TaskDurationValue 

Positive  Decimal  Number 

Yes 

P 

TaskDurationUnit 

Classification  (Duration  Unit) 

Yes 

Q 

TaskStartValue 

Positive  Decimal  Number 

Yes 

R 

TaskStartUnit 

Classification  (Duration  Unit) 

Yes 

S 

TaskFrequencyValue 

Positive  Decimal  Number 

Yes 

T 

TaskFrequencyUnit 

Classification  (Duration  Unit) 

Yes 

U 

Created  By 

Integer  (Foreign  Key) 

Yes 

V 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

w 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

X 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Y 

Withdrawn 

Yes/ No 

Yes 
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Table  5-46.  Worksheet  27:  Startup  (Required). 


WORKSHEET  NAME 

Startup 

CONTENT 

Identification  of  sets  of  sequenced  tasks  needed  to  start  refer¬ 
enced  equipment  or  systems.  If  possible  the  specific  tasks  shall 
be  identified  in  this  worksheet.  Linking  to  a  file  containing 
tasks,  unless  created  by  manufacturers,  should  be  discour¬ 
aged. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

Material,  Tool,  and  Training  resources  are  identified  by  refer¬ 
ence. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

StartUpTaskID 

Integer  (LUID) 

Yes 

B 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

TaskStatus 

Classification  (Task  Status) 

Yes 

D 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

MateriallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

ToollDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

TrainingIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

K 

PriorTaskList 

Integer  List  (Foreign  Keys) 

If  Needed 

L 

Task  Number 

Text  (50) 

Yes 

M 

TaskName 

Text  (50) 

Yes 

N 

TaskDescription 

Text  (255) 

Opt 

0 

TaskDurationValue 

Positive  Decimal  Number 

Yes 

P 

TaskDurationUnit 

Classification  (Duration  Unit) 

Yes 

Q 

TaskStartValue 

Positive  Decimal  Number 

Yes 

R 

TaskStartUnit 

Classification  (Duration  Unit) 

Yes 

S 

TaskFrequencyValue 

Positive  Decimal  Number 

Yes 

T 

TaskFrequencyUnit 

Classification  (Duration  Unit) 

Yes 

U 

Created  By 

Integer  (Foreign  Key) 

Yes 

V 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

w 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

X 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Y 

Withdrawn 

Yes/ No 

Yes 
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Table  5-47.  Worksheet  28:  ShutDown  (Required). 


WORKSHEET  NAME 

Startup 

CONTENT 

Identification  of  sets  of  sequenced  tasks  needed  to  shut  down 
referenced  equipment  or  systems.  If  possible  the  specific  tasks 
shall  be  identified  in  this  worksheet.  Linking  to  a  file  containing 
tasks,  unless  created  by  manufacturers,  should  be  discour¬ 
aged. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

Material,  Tool,  and  Training  resources  are  identified  by  refer¬ 
ence. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

ShutDownTaskID 

Integer  (LUID) 

Yes 

B 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

TaskStatus 

Classification  (Task  Status) 

Yes 

D 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

MateriallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

ToollDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

TrainingIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

K 

PriorTaskList 

Integer  List  (Foreign  Keys) 

If  Needed 

L 

Task  Number 

Text  (50) 

Yes 

M 

TaskName 

Text  (50) 

Yes 

N 

TaskDescription 

Text  (255) 

Opt 

0 

TaskDurationValue 

Positive  Decimal  Number 

Yes 

P 

TaskDurationUnit 

Classification  (Duration  Unit) 

Yes 

Q 

TaskStartValue 

Positive  Decimal  Number 

Yes 

R 

TaskStartUnit 

Classification  (Duration  Unit) 

Yes 

S 

TaskFrequencyValue 

Positive  Decimal  Number 

Yes 

T 

TaskFrequencyUnit 

Classification  (Duration  Unit) 

Yes 

U 

Created  By 

Integer  (Foreign  Key) 

Yes 

V 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

w 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

X 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

Y 

Withdrawn 

Yes/ No 

Yes 
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Table  5-48.  Worksheet  29:  Emergency  (Required). 


WORKSHEET  NAME 

Emergency 

CONTENT 

Identification  of  sets  of  sequenced  tasks  needed  to  compiete 
emergency  operations  on  referenced  equipment  or  systems.  If 
possible  the  specific  tasks  shall  be  identified  in  this  worksheet. 
Linking  to  a  file  containing  tasks,  unless  created  by  manufac¬ 
turers,  should  be  discouraged. 

REQUIRED 

Yes 

PRIMARY  AUTHOR 

Construction  Contractor 

ALTERNATE  AUTHOR 

Subcontractor,  Manufacturer 

OPTIONS 

Material,  Tool,  and  Training  resources  are  identified  by  refer¬ 
ence. 

Column 

Column  Name 

Data  Type 

Reqd 

A 

EmergencyTaskID 

Integer  (LUID) 

Yes 

B 

RegisterlDList 

Integer  List  (Foreign  Keys) 

Yes 

0 

TaskStatus 

Classification  (Task  Status) 

Yes 

D 

DocumentIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

E 

TransmittallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

F 

InstallationIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

G 

SystemIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

H 

MateriallDList 

Integer  List  (Foreign  Keys) 

If  Needed 

1 

ToollDList 

Integer  List  (Foreign  Keys) 

If  Needed 

J 

TrainingIDList 

Integer  List  (Foreign  Keys) 

If  Needed 

K 

PriorTaskList 

Integer  List  (Foreign  Keys) 

If  Needed 

L 

Task  Number 

Text  (50) 

Yes 

M 

TaskName 

Text  (50) 

Yes 

N 

TaskDescription 

Text  (255) 

Opt 

0 

TaskDurationValue 

Positive  Decimal  Number 

Yes 

P 

TaskDurationUnit 

Classification  (Duration  Unit) 

Yes 

DELETED 

TaskStartValue 

Positive  Decimal  Number 

Yes 

DELETED 

TaskStartUnit 

Classification  (Duration  Unit) 

Yes 

DELETED 

TaskFrequencyValue 

Positive  Decimal  Number 

Yes 

DELETED 

TaskFrequencyUnit 

Classification  (Duration  Unit) 

Yes 

Q 

Created  By 

Integer  (Foreign  Key) 

Yes 

R 

Created  Date 

Date  (dd-MMM-yyyy) 

Yes 

S 

CreatedTime 

Time  (local  24-hr  clock) 

Yes 

T 

ReplacesID 

Integer  (Local  Key) 

If  Needed 

U 

Withdrawn 

Yes/ No 

Yes 
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Implementer’s  guide 

This  section  provides  notes  for  those  using  the  COBIE  spreadsheet  as  part 
of  automated  import/export  routines.  Information  related  to  the  manual 
loading  of  COBIE  data  into  a  spreadsheet  is  provided  in  the  next  section. 

The  mapping  between  lEC  and  specific  COBIE  worksheets  is  being  com¬ 
pleted  and  will  be  provided  under  separate  cover  through  the  IDM  Wiki 
rhttp://idm.bmldingsmart.no/confluence/display/IDM/North+America1. 

General  notes 

The  COBIE  Pilot  Implementation  Standard  is  a  Microsoft  Excel  formatted 
spreadsheet.  This  spreadsheet  is  comprised  of  29  worksheets  identified  in 
this  report.  All  worksheets  are  required  to  be  provided  in  every  COBIE  file 
exchange.  Worksheets  are  required  to  be  submitted  in  the  order  identified 
in  this  document.  All  worksheets  will  contain  the  column  headers  as  noted 
in  Section  o.  Worksheets  not  required  by  a  specific  set  of  construction 
specifications,  or  whose  data  is  not  available  given  the  context  of  a  specific 
information  exchange  will  be  blank. 

The  first  worksheet,  “Instructions,”  and  the  last,  “Addl.  Pick  Lists,”  should 
be  provided  with  every  file.  Eor  files  produced  by  software  systems,  how¬ 
ever,  these  worksheets  may  be  blank. 

Linear  and  area  units  of  measure  are  found  throughout  the  spreadsheet.  It 
is  assumed  that  these  units  of  measure  will  be  set  to  the  same  value. 
Translation  to  a  common  unit  of  measure  used  throughout  the  spread¬ 
sheet  is  required. 

The  goal  of  the  COBIE  spreadsheet  is  to  help  remove  people  from  data 
transcription  activities.  Until  a  full  set  of  software  tools  is  provided  for  this 
data  life  cycle,  it  is  likely  that  some  users  will  directly  update  the  spread¬ 
sheet  itself,  using  the  sample  spreadsheet  as  a  starting  point. 

To  improve  the  usability  of  the  spreadsheet,  for  those  users  who  need  to 
manually  enter  data  into  the  spreadsheet,  a  calculated  foreign  key  lookup 
field  has  been  included  as  the  last  column  in  many  worksheets  of  the  blank 
sample  worksheet.  This  calculated  lookup  list  column  is  not  required  to  be 
imported  or  exported  but  does  have  a  minor  implication  for  software  im- 
plementers.  The  user  selection  of  a  foreign  key  may  (or  may  not)  result  in  a 
comma-delimited  list  that  contains  the  ID  number  of  the  referenced  re- 
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cord  as  well  as  the  name  (or  other  ‘human  readable’  text)  for  the  record. 
Vendors  should  test  all  foreign  key  integer  fields  during  import  and  only 
import  the  first  value  in  the  list,  i.e.,  the  foreign  key. 

Vendors  exporting  COBIE  data  do  not  need  to  include  the  ID  Pick  columns 
and  may  provide  only  the  ID  number  of  the  foreign  key. 

In  all  cases  the  ID  lists  will  be  only  comma-delimited  lists  of  foreign  keys. 

Notes  on  change  history 

Section  o  identifies  the  method  that  is  required  to  track  changes  within  the 
COBIE  spreadsheet.  If  COBIE  data  is  being  updated,  new  full  data  records 
must  be  provided  that  reference  the  replaced  ID  of  the  original  records  are 
required.  The  user  entering  the  information  into  the  COBIE  spreadsheet 
shall  also  be  recorded  with  every  record.  To  the  extent  practical  the  user 
identified  should  be  the  actual  person  creating  the  information,  not  some¬ 
one  who  may  have  assisted  in  data  transcription  into  the  COBIE  spread¬ 
sheet.  If  the  original  author  is  not  known,  then  the  data  transcriber  or  per¬ 
son  preparing  the  COBIE  spreadsheet  will  be  identified  as  the  author  of 
the  record. 

During  the  process  of  creating  COBIE  data  during  design  and  construc¬ 
tion,  records  may  not  be  removed  from  later  submissions  of  a  COBIE 
spreadsheet  once  the  spreadsheet  has  begun  to  be  used  (or  has  been  sub¬ 
mitted  to  the  owner).  Records  may  either  be  replaced  or  withdrawn.  With¬ 
drawing  requires  the  addition  of  a  replacement  record,  that  date-stamps 
the  time  and  author  of  the  withdraw  action.  This  new  replacement  record 
will  have  the  “Withdrawn”  column  set  to  “Yes.” 

Implementers  should  note  that  only  non-superseded,  non-withdrawn  rows 
contain  the  current  data  set. 

Manufacturer-provided  information 

Current  industry  practice  is  for  manufacturers  to  provide  their  data  in  pa¬ 
per  or  electronic  paper  formats  (such  as  PDE).  COBIE  can  support  this 
method  of  data  transfer,  even  though  this  is  not  the  most  helpful  method 
of  transfer  for  such  data. 

When  provided  by  the  manufacturers’  spare  parts,  resources,  and  job 
plans  should  be  individually  provided.  It  is  likely  that,  in  the  short  term. 
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such  information  will  continue  to  have  to  be  manually  extracted  out  of 
these  documents  rather  than  used  as  a  direct  import.  Vendors  should 
check  the  validity  of  the  spare  part,  resource,  and  job  plan  data  prior  to  di¬ 
rectly  importing  COBIE  data. 

Worksheet  01:  Contact  notes 

All  persons  and  organizations  referenced  in  the  COBIE  spreadsheet  must 
be  identified  in  the  Contact  worksheet.  The  minimum  set  of  persons  and 
organizations  listed  in  the  Contact  worksheet  would  occur  when  a  single 
individual  from  a  construction  contractor  is  identified  to  compile  the  en¬ 
tire  COBIE  data  at  project  handover.  In  this  case,  the  person  compiling  the 
information,  warranty  guarantors,  and  spare  parts  providers  would  be  the 
only  records  identified  in  the  spreadsheet. 

All  records  in  all  worksheets  are  required  to  be  identified  by  the  ContactID 
of  the  user  who  entered  the  data  in  the  COBIE  spreadsheet.  The  date  and 
time  for  this  information  is  provided.  Additional  discussion  of  this  re¬ 
quirement  is  found  in  Section  o. 

Worksheet  02:  Facility  notes 

A  minimum  of  one  record  is  required  in  the  Eacility  worksheet.  In  most 
cases  this  will  represent  the  name  of  the  project  whose  data  is  contained  in 
the  COBIE  spreadsheet.  In  cases  where  multiple  buildings  or  projects  are 
contained  in  a  single  contract,  the  Eacility  worksheet  may  contain  multiple 
records. 

The  use  of  owner-based  real  property  identifiers  may  be  accomplished 
through  the  external  reference  fields  in  the  Contact,  Eacility,  and  other 
worksheets. 

Worksheet  03:  Floor  notes 

A  minimum  of  one  record  is  required  in  the  Eloor  worksheet.  The  Eloor 
worksheet  is  typically  used  to  define  vertical  spaces  within  a  given  project. 
The  Eloor  worksheet  may  also  be  used  to  define  site  or  geographically- 
oriented  volumes  related  to  civil  works,  highway  or  other  horizontal  pro¬ 
jects. 


ERDC/CERLTR-07-30 


160 


Worksheet  04:  Space  notes 

The  Space  worksheet  is,  for  a  typical  building  simply  the  list  of  rooms  in 
the  building.  Later  information  about  the  location  of  equipment  is  linked 
to  the  space  worksheet  to  create  the  list  of  installed  equipment. 

Spaces  may  include  zones,  such  as  circulation  zones,  by  nesting  spaces. 
Spaces  may  also  be  grouped  to  identify  physical  building  areas  such  as 
“wings”. 

Worksheet  05:  System  notes 

Systems  may  include  zoning  to  identify  differences  in  fire  protection, 
alarm  systems,  or  HVAC  coverage. 

Worksheet  06:  Register  notes 

The  register  worksheet  is  the  catalog  of  all  materials,  products,  and 
equipment  types  that  are  included  in  the  facility.  This  information  must  be 
identified  by  selecting  a  RegisterType  value  of  “ProductData”.  Items  in  this 
table  identified  as  “Product  Data”  may  be  used  to  create  product  types  or 
classes. 

In  addition  the  register  contains  the  set  of  all  submittals  identified  by  the 
designer  that  are  required  of  the  construction  contractor. 

The  standard  “submittal  register,  from  the  point  of  view  of  a  BIM,  is  a 
catalog  of  all  the  materials,  products,  and  equipment  and  information 
about  these  items.  The  submittal  register  is  the  key  point  of  integration  be¬ 
tween  the  designers’  requirements  contained  in  specifications  and  the  con¬ 
struction  contractors’  supply  chain.  COBIE  employs  this  critical  interface 
to  capture  manufacturer  provided  data  as  it  is  provided  (or  becomes  avail¬ 
able). 

Worksheet  07:  Component  notes 

The  component  worksheet  allows  the  designer  to  identify  the  location  of 
named  equipment,  e.g.,  “AHU-i”,  within  the  building.  The  Installation 
worksheet  allows  the  construction  contractor  to  identify  the  serial  number 
for  that  named  equipment.  If  the  construction  contractor  is  creating  the 
equipment  list  at  construction  handover  the  Installation  worksheet  may 
used  alone,  as  it  reflects  the  as-built  conditions  of  the  building. 
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Worksheet  08:  Attribute  notes 

Spare  parts,  instructions,  and  other  documents  often  are  prepared  by 
manufacturers  as  part  of  the  same  document.  It  is  expected  that  the  con¬ 
struction  contractor  will  not  provide  a  single  PDF  file  with  all  information. 
The  construction  contractor  should  break  the  document  into  constituent 
parts,  as  identified  in  COBIE,  where  possible. 

Worksheet  08:  Attribute  notes 

A  minimum  of  one  value  for  Columns  C  -  H  must  be  selected  for  a  record 
to  be  valid. 

Worksheet  09:  Coordinate  notes 

A  minimum  of  one  value  for  Columns  C  -  G  must  be  selected  for  a  record 
to  be  valid.  All  coordinates  are  provided  relative  to  the  building’s  local  ori¬ 
gin  0,0,0  point. 

Worksheets  10, 12, 13:  Quaiity  assurance  notes 

Worksheets  lo,  12,  and  13  are  included  to  describe  the  data  needed  to 
process  and/or  approve  documents  submitted  against  Register  require¬ 
ments.  This  data  is  optional.  If  available,  such  information  may  be  pro¬ 
vided  in  COBIE  as  documentation  of  technical  issues  that  may  have  arisen 
on  specific  submittals. 

Worksheet  16:  Warranty  notes 

In  addition  to  the  name  and  dates  associated  with  a  warranty,  identifica¬ 
tion  of  warranties  requires  a  reference  to  the  original  warranty  certifi- 
cate(s)  (DocumentIDList),  the  equipment  type(s)  covered  by  the  warranty 
(RegisterlDList),  and  the  point(s)  of  contact  responsible  for  the  warranty 
call  (GuarantorlDList). 

Worksheet  17:  Spare  notes 

This  worksheet  includes  spare  parts  on  site,  replacement  parts  that  require 
ordering,  and  lubricants  that  are  needed  for  equipment  operation.  The 
Spare  Type  field  allows  users  to  distinguish  between  these  two  types  of 
parts. 
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As  with  warranty  data,  replacement  part  data  must  include  a  reference  to 
the  original  parts  diagram(s)  (DocumentIDList),  the  equipment  type(s) 
covered  by  the  s  diagram(s)  (RegisterlDList),  and  one  or  more  suppliers 
who  can  indicate  who  is  able  to  supply  replacement  parts  (Guaran- 
torlDList). 

Worksheets  21  -  23:  Resource  notes 

Data  contained  in  the  material,  tool,  and  training  worksheets  must  be  ref¬ 
erenced  at  least  once  in  the  job  plan  worksheets  (i.e.,  24  -  29). 

Worksheets  21  -  23:  Job  Plan  notes 

Manufacturers  often  specify  that  equipment  should  be  greased,  checked, 
or  adjusted  “periodically.”  Such  requirements  should  be  reviewed  by  ex¬ 
perienced  O&M  staff  to  ensure  that  a  reasonable  period  between  such  ad¬ 
justments  is  defined  in  the  COBIE  data  file  prior  to  CMMS  import. 

User’s  guide 

The  objective  of  the  COBIE  standard  is  to  enable  software  vendors  to  pro¬ 
vide  direct  import/ export  support  for  COBIE  based  on  the  parts  of  the 
building  process  on  which  those  software  systems  are  focused.  Until  a  full 
suite  of  tools  are  developed  and  widely  available,  it  is  expected  that  users 
may  need  to  directly  input  data  into  the  spreadsheet.  This  section  provides 
some  key  insights  based  on  early  pilot  testing  of  the  standard. 

The  user  guide  contained  in  the  following  paragraphs  is  a  general,  more 
technical  discussion  of  the  documents  that  may  be  directly  obtained  from 
the  Whole  Building  Design  Guide  at  http://www.wbdg.org.  A  WBDG  “Re¬ 
source  Page”  will  provide  links  to  a  template  spreadsheet,  a  step-by-step 
guide  to  manually  completing  the  spreadsheet,  a  COBIE  overview  docu¬ 
ment,  a  COBIE  briefing,  and  a  copy  of  this  technical  report.  The  informa¬ 
tion  provided  below  provides  a  more  abstract  description  that,  for  techni¬ 
cal  readers,  can  supplement  the  step-by-step  guide. 

Template  spreadsheet 

The  order  and  naming  of  the  worksheets  shall  not  be  changed.  The  order 
and  naming  of  column  headings  within  each  spreadsheet  shall  not  be 
changed.  Color  coding  of  the  blank  spreadsheet  should  be  maintained,  in 
the  new  records,  to  allow  users  who  are  entering  data  by  hand,  or  checking 
data  to  spot-check  for  required  data  fields. 
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As  records  are  added  to  the  blank  spreadsheet  the  formulas  in  the  spread¬ 
sheet  will  need  to  be  copied  to  the  new  records.  Someone  with  experience 
in  using  Excel  formulas,  and  lookup  lists,  should  be  responsible  for  ex¬ 
panding  the  spreadsheet  for  the  total  number  of  rows. 

Records  that  are  not  filled  out  in  the  blank  spreadsheet  should  be  removed 
prior  to  submission  of  the  spreadsheet.  Required  data  that  is  not  available 
at  the  time  when  the  file  is  submitted  should  be  left  blank. 

In  some  cases,  users  may  wish  to  track  additional  information  in  the 
spreadsheet.  This  is  permitted.  User  defined  information  columns  shall  be 
placed  within  the  appropriate  worksheet  to  the  right  of  all  COBIE  data 
columns. 

Process  orientation 

COBIE  worksheets  are  organized  based  on  when  the  data  is  created,  there¬ 
fore,  data  loading  should  begin  with  worksheet  one  and  proceed  through 
the  project.  Data  in  later  worksheets  references  data  in  earlier  worksheets. 
As  a  result,  you  must  begin  to  load  data  starting  with  the  design  work¬ 
sheets  then  and  follow  through  to  the  construction,  installation,  and  com¬ 
missioning  worksheets. 

Authorship 

The  person  entering  the  data  into  the  COBIE  spreadsheet  should  be  identi¬ 
fied  as  the  first  data  row  in  the  Contact  Worksheet.  This  user  will  be  iden¬ 
tified  with  all  other  data  in  the  spreadsheet  under  the  “CreatedBy”  column. 

Designer  data 

Starting  with  the  Eacility  Worksheet,  the  user  should  begin  to  enter  the 
data  about  the  building  in  order  Eacility,  Eloor,  and  Space.  Note  that  the 
area  measurements  for  the  Eloors  and  Spaces  are  not  mandated  (unless 
required  by  contract).  If  direct  data  transfer  or  room  lists  do  not  already 
exist  this  information  can  be  quickly  identified  directly  from  contract 
drawings.  Ask  the  facility  owner  if  they  have  a  “facility  id”  or  other  num¬ 
bers  they  would  like  added  to  the  external  reference  columns  to  assist 
them  to  load  COBIE  data  following  construction. 

The  Register  worksheet  is  used  in  the  COBIE  (which  is  really  a  simplified 
BIM)  to  identify  all  the  types  of  materials,  products,  and  equipment  in  the 
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building.  Often  the  submittal  register  is  already  provided  in  electronic 
format  and  can  be  manipulated  to  be  copy  and  pasted  into  COBIE.  Once 
the  data  is  pasted  into  COBIE,  links  between  all  items  identified  as  “Prod¬ 
uct  Data”  and  their  respective  systems,  and  room  numbers  is  required. 

The  Component  worksheet  identifies  specifically  named  items  that  are 
specific  instances  of  items  found  in  the  Register.  Eor  example  the  Register 
would  include  a  requirement  for  a  pump  with  specified  capacity.  The 
Component  worksheet  would  identify  that  there  are  three  of  these  pumps 
in  the  facility  with  names  “Pump-i”,  “Pump-2”,  and  “Pump-3”.  Items  may 
also  be  identified  by  tag  numbers  as  noted  in  the  design  drawings. 

If  data  is  being  created  in  the  absence  of  a  submittal  register,  in  the  case  of 
COBIE  data  being  created  by  those  not  directly  involved  in  the  original 
construction  project,  the  data  commissioning  consultant  should  begin  by 
listing  each  named  and  tagged  item  found  on  the  as-built  construction 
drawings  and  add  those  to  the  Component  Worksheet.  Erom  there,  the 
consultant  can  “back-into”  the  register  by  identifying  the  standard  product 
types  two  which  these  products  belong. 

Note  that  attribute  and  coordinate  data  are  not  required  worksheets.  If  the 
data  set  is  being  created  by  hand  these  worksheets  will  typically  not  be  re¬ 
quired.  Users  should  consult  their  specific  contract  to  determine  if  these 
worksheets  are  explicitly  required. 

Quality  control/assurance  data 

If  an  electronic  submittal  process  is  being  used  to  support  COBIE,  little 
additional  effort,  beyond  that  required  to  execute  the  submittal  and  re¬ 
view/approval  process  will  be  needed  to  capture  documents  for  COBIE. 
Unfortunately,  many  users  do  not  have  access  to  a  fully-electronic  submit¬ 
tal  review  process  and,  today,  hand  manipulation  of  manufacturers’  data 
will  be  required. 

If  COBIE  data  is  being  recreated  manually,  the  contractors’  submission 
process  is  not  expected  to  be  recreated  in  the  QC/QA  worksheets  (10, 12, 
and  13).  Documents  in  Worksheet  11  shall  be  provided.  The  documents 
listed  in  Worksheet  11  are  those  provided  directly  by  a  single  manufacturer 
for  a  single  product.  If  the  manufacturers’  document  exceeds  25  pages, 
then  the  document  will  likely  pertain  to  many  different  references  of 
COBIE  data  found  later  in  the  spreadsheet.  In  general,  COBIE  data  should 
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be  decomposed  into  specific  parts  that  allow  the  document  to  be  linked  to 
a  single  referenced  item  appearing  in  later  spreadsheets. 

Installing  equipment 

When  equipment  is  installed  the  user  entering  data  into  COBIE  will  select 
the  specific  named  item  from  the  class  of  item  from  the  Register  ID  list. 

If  the  item  installed  is  also  listed  in  the  Component  worksheet,  then  the 
Component  ID  value  must  also  be  selected. 

Warranty  information 

Warranty  information  found  in  worksheet  i6  must  include  the  warranty 
certificate(s)  referenced  in  the  DocumentIDList,  the  submittal  Register  to 
identify  the  product  class  in  the  RegisterlDList,  and  the  list  of  companies 
that  are  assigned  to  complete  warranty  work  -  GuarantorlDList.  To  be 
listed  in  these  columns  data  must  have  already  been  entered  in  the  Docu¬ 
ment,  Register,  and  Contact  worksheets.  Warranties  records  in  COBIE 
shall  also  identify  the  name,  start  date,  and  end  date  for  the  warranty. 

Spare  and  repiacement  parts  information 

The  Spare  worksheet  contains  information  on  spare  parts,  ordering  infor¬ 
mation  for  replacement  parts  and  required  lubricants.  The  SpareType  field 
allows  the  user  to  distinguish  between  these  different  types  of  parts  related 
data. 

As  with  warranty  data  each  record  must  include  the  document  containing 
spare  parts  diagrams,  DocumentIDList,  the  submittal  Register  to  identify 
the  product  class  in  the  RegisterlDList,  and  the  list  of  companies  from 
whom  parts  may  be  ordered  or  re-ordered  -  SpareProviderlDList.  To  be 
listed  in  these  columns  data  must  have  already  been  entered  in  the  Docu¬ 
ment,  Register,  and  Contact  worksheets. 

Change  management 

Requests  for  changes  to  COBIE  and  this  document  may  be  submitted  di¬ 
rectly  to  the  author  of  this  document.  Comments  will  be  evaluated  and  in¬ 
corporated  by  the  NBIMS  Consensus  Committee  and  released  as  the 
COBIE  Consensus  Implementation  Standard. 
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The  July  2007  release  contains  input  from  project  stakeholders  represent¬ 
ing  Computerized  Maintenance  Management  System  (CMMS),  data  com¬ 
missioning  consultants,  and  members  of  the  IFC  Model  Support  Group. 
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6  COBIE  Data  Compatibility  with  IFC 

The  previous  chapters  identified  the  process  maps,  described  the  required 
information  exchanges  needed  for  COBIE,  and  defined  a  spreadsheet  that 
may  be  created  to  explain  the  data  being  exchanged  in  COBIE.  To  map 
those  information  exchanges  to  the  lEC  model,  the  Information  Delivery 
Manual  (IDM)  process  [Wix  2007]  was  also  used.  The  detailed  definition 
of  Exchange  Requirements  and  Eunctional  Parts  required  by  the  IDM 
process  that  describe  COBIE  may  be  found  at  IDMWiki  2007 
rhttp://idm.buildingsmart.no/confiuence/displav/IDM/North+America1. 

Efforts  are  currently  under  way  to  create  several  sets  of  COBIE  data  from 
real  projects,  based  on  the  pilot  implementation  standard.  Translators  be¬ 
tween  the  COBIE  data  and  the  IfcXML  format  have  already  been  devel¬ 
oped.  Use  of  this  IfcXML  file  is  seen  as  an  intermediate  format  to  allow  the 
transmission  of  BIM  data  from  designers  for  the  purpose  of  kick-starting 
the  COBIE  data.  The  results  of  these  current  efforts  will  be  published  upon 
their  completion. 
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7  COBIE  Pilot  Testing  Specification 

Specifications  for  the  use  of  COBIE  on  design-build  projects  for  the  Corps 
of  Engineers  Louisville  and  Seattle  District  offices  were  developed  by 
specification  writers  at  the  Louisville  District.  There  are  three  types  of  in¬ 
clusions  to  the  design-build  request  for  proposal.  The  first  relates  to  sub¬ 
mittals  and  is  shown  below: 

SD-03  Product  Data 

COBIE  Standard  Tables 

Three  data  sets  of  the  completed  COBIE  tables  containing 
all  as-built,  approved  and  final  information.  The  data  sets 
shall  include  both  the  COBIE  spreadsheet  and  all  indexed, 
entered,  referenced  or  linked  information.  The  spreadsheets 
shall  be  fully  functional  and  in  compliance  with  the  Con¬ 
struction  Operations  Building  Information  Exchange  (COBIE) 
Format  Specification.  Each  data  set  shall  be  provided  on 
compact  disk(s)  with  proper  instructions  and  labeling  so 
that  individuals  not  familiar  with  the  process  can  utilize 
the  provided  information. 

The  second  area  where  Corps  of  Engineers  design-build  requests  for  pro¬ 
posals  were  updated  relates  to  several  places  including  “Equipment  In- 
Place,”  as  shown  in  the  paragraph  below. 

1.3.  EQUIPMENT  DATA 

1.3.1.  Real  Property  Equipment 

Provide  an  electronic  version  (compliant  with  the  COBIE 
format  specification)  of  the  Equipment-in-Place  list  and 
all  information  included;  enter  and/or  index  the  data  into 
the  COBIE  Standard  spreadsheet  in  compliance  with  the  Con¬ 
struction  Operations  Building  Information  Exchange  (COBIE) 
Format  Specification. 
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The  final  place  where  USAGE  design-build  requests  for  proposals  were 
updated  relates  to  a  meeting  held  6o  days  prior  to  facility  handoff.  This 
“Red  Zone  Meeting”  includes  the  following  bullet  item  that  must  be  ad¬ 
dressed: 


"Provide  COBIE  Standard  Tables  to  Customer" 


A  generic  sample  of  contract  language  for  construction  contractors  to 
submit  handover  data  in  COBIE  format  in  lieu  of  existing  paper  docu¬ 
ments  is  provided  in  the  paragraphs  below: 

The  Contractor  shall  have  the  option  of  providing  two 
(2)  electronic  copies  of  handover  documents  in  lieu  of 
the  standard  requirement  to  provide  binders  of  paper 
documents. 

The  National  Building  Information  Model  Standard 
(NBIMS)  COBIE  format  shall  be  required  for  this  elec¬ 
tronic  exchange.  The  COBIE  standard  specifies  re¬ 
quirement  for  the  indexing  and  submission  of  Port¬ 
able  Document  Eormat  (PDE)  and  other  appropriate 
file  formats  that  would  otherwise  be  printed  and  sub¬ 
mitted  in  compliance  with  project  handover  require¬ 
ments.  In  2007  and  2008  the  COBIE  index  shall  be  a 
Microsoft  Excel  Spreadsheet  as  provided  by  the 
NBIMS  organization  through  their  web  site: 
www.nbims.org. 

The  Construction  Contractor  is  responsible  to  provide 
data  for  all  COBIE  worksheets  with  the  following  ex¬ 
ceptions: 

(1)  Unless  otherwise  noted,  the  Designer  of  Record 
shall  be  required  to  provide  information  identified  in 
the  COBIE  Pilot  Implementation  Standard  “Design” 
worksheets.  These  include  worksheet  2  “Eacility,” 
worksheet  3  “Eloor”,  worksheet  4  “Space”,  worksheet 
5  “System”,  worksheet  6  “Register”,  worksheet  7 
“Component”,  worksheet  8  “Attribute”,  and  worksheet 
9  “Coordinate.”  The  Construction  Contractor  shall  add 
additional  information  to  this  set  of  Design  work- 
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sheets  to  reflect  as  built  conditions  of  the  facility  in 
accordance  with  the  change  management  instructions 
provided  in  the  COBIE  Pilot  Implementation  Stan¬ 
dard. 

(2)  If  data  is  not  provided  by  the  Designer  of  Record, 
the  Construction  Contractor  shall  be  required  to 
document  the  as-built  facility  by  completing  work¬ 
sheet  2  “Facility,”  worksheet  3  “Floor”,  worksheet  4 
“Space”,  worksheet  5  “System”,  and  worksheet  6  “Reg¬ 
ister”. 

(3)  If  data  is  not  provided  by  the  Designer  of  Record, 
the  Construction  Contractor  shall  document  as-built 
locations  of  installed  and/or  tagged  equipment  and 
building  components  by  completing  worksheet  14  “In¬ 
stallation”. 

(3)  If  submittal  processing  information  is  to  be  ex¬ 
changed  using  COBIE,  the  Construction  Contactor 
shall  document  this  process  by  completing  worksheets 
10  “Schedule”,  12  “Transmit”.  The  Construction  Man¬ 
ager  or  Owner’s  Representative  will  use  worksheet  13 
“Approve”  to  document  the  results  of  their  reviews. 

Requests  for  information  on  the  COBIE  data  exchange 
standard  may  be  provided  by  email  request  to 
bill.east@us.army.mil.  Telephonic  requests  will  not  be 
accepted.  Those  making  direct  email  inquiry  should 
expect  replies  to  take  between  fourteen  (14)  and  thirty 
(30)  days.  Inquiries  containing  contractual  queries 
will  be  returned  to  the  sender  with  a  note  that  such  is¬ 
sues  must  be  addressed  to  contracting  personnel  for 
resolution. 

The  two  (2)  copies  of  COBIE  shall  be  submitted  on 
Compact  Disk  (CD)  and  checked  for  read  errors  prior 
to  submittal.  One  (1)  copy  shall  be  labeled  as  the  “File 
Copy”.  The  other  copy  shall  be  labeled  as  the  “Work¬ 
ing  Copy.”  The  name  of  the  project,  contract  number, 
and  contact  information  for  the  person  creating  the 
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disk  will  also  be  included  on  the  disk  label.  In  case  the 
facility  operator  is  unable  to  retrieve  information  from 
the  CDs,  the  Contractor  is  responsible  to  provide  one 
additional  a  copy  of  the  electronic  data  available  dur¬ 
ing  the  warranty  period  of  the  contract  (identified 
elsewhere  in  the  specifications). 
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8  Conclusions 

Adoption  follows  practice 

During  the  course  of  developing  this  standard  it  has  become  clear  that 
standards  development  will  not  succeed  unless  the  standard  follows  the 
practices  used  in  industry.  Forward-looking  standards  that  attempt  to  lead 
an  industry,  such  as  those  developed  by  the  lAI,  cannot  be  implemented 
until  common  practice  in  the  industry  “catches  up.”  Fortunately  for  the 
COBIE  project,  large  construction  firms  and  facility  operators  are  increas¬ 
ingly  becoming  interested  in  capturing  facility  data.  The  means  for  captur¬ 
ing  the  data,  during  the  construction  quality  assurance  process,  are  well 
established;  and  the  primary  medium  for  documenting  it,  the  PDF  file,  is 
ubiquitous.  The  use  of  forms,  spreadsheets,  and/or  XML  files  to  exchange 
data  is  also  well  understood  by  larger  public  and  private  A/E/C/0  organi¬ 
zations. 

Business  process  software 

Eor  business  process  software  tools  to  succeed,  owner-oriented  implemen¬ 
tations  of  the  COBIE  exchange  requirements  must  go  beyond  the  standard 
model  of  submittal  registers  provided  by  owner  agencies.  Owner-based 
software  tools  must  provide  means  for  transaction-based  information  ex¬ 
change  in  the  context  of  the  complete,  complex  supply  chains.  In  these  sys¬ 
tems,  prime  contractors  are  able  to  receive  information  from  manufactur¬ 
ers,  suppliers,  and  subcontractors  needed  to  submit  in  compliance  with 
the  COBIE  specification. 

Multiple  models  and  standards 

Many  organizations  are  working  on  developing  standards  related  to  the 
A/E/C/0  space.  Each  standard  contains  information  that  the  standards 
developer  considers  critical  to  its  constituents.  Those  developing  other 
portions  of  the  National  Building  Information  Modeling  Standard  will, 
undoubtedly,  come  across  a  similarly  complex  space  of  standards  and 
standards  bodies. 

It  is  useful  to  recall  what  the  statistician  George  Box  said:  “All  models  are 
wrong,  some  are  useful”  [Box  1979].  The  implication  of  his  statement  is 
that  there  is  room  for  multiple,  overlapping  models  of  the  A/E/C/0  space 
because  different  constituents  focus  on  different  useful  aspects.  These  dif- 
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ferences  will  even  be  evident  as  owners  begin  to  require  COBIE  data.  For 
example,  owners  who  require  their  own  space  function  taxonomy  should 
specify  that  scheme  in  place  of  the  default  OmniClass  space  function. 

Other  changes  that  may  be  relevant  for  owner-specific  applications  of 
COBIE  are  area-calculation  methods  and  asset  management  definitions. 
Adoption  of  any  BIM  standard  must  be  accomplished  within  the  context  of 
the  project  team. 

Evaluating  implementations 

During  the  course  of  this  project  participants  have  debated  the  role  of  test¬ 
ing  and  product  certification.  There  are  many  non-intersecting  concepts 
and  approaches  to  standards  and  compliance.  From  the  author’s  point  of 
view,  the  most  authoritative  definition  of  standards  compliance  is  pro¬ 
vided  by  the  Open  Source  Initiative.  The  open  standards  definition  [OSI 
2006]  describes  two  different  levels  of  interaction  with  open  standards:  (1) 
the  compatible  level  allows  a  vendor  to  self-certify  its  use  of  the  standard; 
(2)  the  conformant  level  requires  that  an  independent  party  certify  the 
vendor’s  successful  adoption  of  the  standard.  The  COBIE  Pilot  standard 
was  developed  with  the  goal  of  open  source  compatibility. 
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9  Recommendations 

Begin  COBIE  pilot  testing 

The  NBIMS  organization  is  currently  working  toward  establishing  a  formal 
process  for  establishing  NBIMS-branded,  IFC-compliant  standards.  The 
current  lack  of  a  formal  process,  however,  does  not  prohibit  early  adopters 
who  require  COBIE  data  from  implementing  their  own  pilot  tests  of  the 
COBIE  specification.  The  construction  contractors  on  the  COBIE  team 
have  determined  that  their  time  and  cost  will  be  reduced  if  owners  imple¬ 
ment  COBIE.  As  one  member  of  the  team  stated,  “It  is  easier  to  make  one 
PDE  file  than  it  is  to  make  and  track  12  paper  copies  of  a  submittal.” 

Adopt  COBIE  pilot  standard 

COBIE  and  the  phased  release  of  updated  specifications,  based  on  the  plan 
identified  in  this  report,  should  be  adopted  by  the  NBIMS  as  a  pilot  infor¬ 
mation  exchange  standard.  Eollowing  adoption,  the  Consensus  and  Opera¬ 
tional  Standards  phase  of  NBIMS  efforts  will  begin.  Given  the  owners’ 
need  for  COBIE,  vendors  should  begin  early  adoption  efforts  using  the 
IEC2X3  coordination  view  as  the  starting  point  for  a  facility  management 
view  definition. 

Adopt  open  standards  definition 

In  order  to  effectively  communicate  the  requirements  of  NBIMS  to  create 
open  standards,  a  formal  definition  of  those  standards  should  be  adopted. 
The  essential  components  of  that  definition  have  already  been  evaluated 
and  are  provided  through  the  Open  Source  Initiative  [OSI  2006]. 

Create  an  open-standards  repository 

As  individual  NBIMS  standards  are  developed,  there  are  pieces  of  those 
standards  that  will  result  in  similar  exchange  requirements  and  individual 
functional  parts.  A  national  database  of  those  requirements  and  parts 
should  be  adopted  by  NBIMS  to  ensure  that  standards  are  reused  to  the 
greatest  extent  possible.  Through  the  compilation  of  these  individual  ex¬ 
change  requirements,  future  standards  could  even  be  constructed  on  an 
ad-hoc  basis.  The  best  current  example  of  such  a  repository  is  maintained 
by  the  government  of  Norway  [Norwegian  buildingSMART  Project  2007]. 
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Open  standards  dictionary  participation 

To  coordinate  the  multiple  semantics  associated  with  various  information 
exchange  requirements,  an  open-source  international  dictionary  is  re¬ 
quired.  Such  an  effort  is  currently  under  way  in  Europe.  It  is  recom¬ 
mended  that  the  NBIMS  participate  in  and  adopt  this  international  lexi¬ 
con. 
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Arlington,  VA  22219 

U.S.  Army  Engineer  Research  and  Development  Center 
Construction  Engineering  Research  Laboratory 
2902  Newmark  Drive 
Champaign,  IL  61822 

U.S.  Army  Engineer  Research  and  Development  Center 

Information  Technology  Laboratory 

CADD/GIS  Technology  Center 

3909  Halls  Ferry  Road 

Vicksburg,  MS  39180-6199 

Headquarters,  U.S.  Army  Corps  of  Engineers  (USACE) 

441 G  Street  NW 
Washington,  DC  20314-1000 


